>
>
> With pid_t, however, I just don't see it. It is now guaranteed to be
> integral. It is only tied to id_t by saying that it will fit into an id_t,
> which obviously allows it to be smaller. As far as mega clustering
> applications of the type you describe, I don't see any reason you would
> need to map every distrubuted process slice as a pid_t. From what I have
> seen, it makes most sense to give each job/task a pid which looks up into
> a table which has information on where the pieces of the job are running,
> including their host and foreign process id.
Actually, having done two very large distributed systems in the
past, with a goal towards a "single system image", it was a requirement
that a single PID namespace be available across all nodes of the
distributed system, and 32-bits was pushing the limits for some of
the configurations we had built as well as envisioned. However,
64-bit systems are coming along soon enough.
However, I do believe that pid_t must always be able to be cast to
a long without loss, likewise uid_t, gid_t.
scott
|