Collective resource limits status report #3

pluknet pluknet at
Thu Jun 24 08:43:30 UTC 2010

On 24 June 2010 11:32, Gabor Kovesdan <gabor at> wrote:
> El 2010. 06. 23. 14:44, pluknet escribió:
>> On 23 June 2010 12:50, Gabor Kovesdan<gabor at>  wrote:
>>>> +typedef __uint32_t     __jid_t;
>>> This has to be signed because calls may return -1.
>> It might return jid_t (-1) then as it's done similarly for getpid(2)
>> family
>> which return pid_t(-1) on error, or similarly for inet_addr(3) which
>> returns
>> INADDR_NONE (0xffffffff, or -1 for uint32_t, let it be signed) on error.
> In the meantime, I've found this:
> Now, I changed it back because some applications may expect it to be a
> 64-bit variable then, and we are not sure about its relation to uid_t yet,
> so we may provide higher capacity.

Hey, it's even more interesting than I could imagine.
uid_t, pid_t here are signed types as well, int32_t or long, depending
on machine type.
That probably explains why jid_t has also a signed type (e.g. might inherit it).
Upper bits in jid_t are reserved for machine ID (has signed int type),
used also in IRIX array sessions. That's why jid_t has to be 64-bit capable.


More information about the soc-status mailing list