Re: Tread/Task IDs

[Peter 'p2' De Schrijver]

On Tue, May 06, 2003 at 11:37:43PM +0200, Marcus Brinkmann wrote:
> Hi,
> 
> of course I can not answer the question why 64 bit data types are not used
> on 32 bit arches, except maybe that the word size on 32 bit arches is 32
> bit, and thus that's the best type to use for every other reason than the
> limitation that imposes on the number of bits (like performance, atomicity,
> alignment, etc).
> 

Atomicity might be an issue yes.

> On Tue, May 06, 2003 at 04:37:31PM -0400, address@hidden wrote:
> > I admit I have only dabbled in kernel space and I usually do cryptographic
> > stuff in userspace with 128-bit or 256-bit IDs.  Maybe I'm just jaded from
> > huge IDs.  However, it would seem to me that there would be many fewer hacks
> > if IDs were at least 32-bits, if not 64-bits.
> 
> The whole thread id is 32 bit on 32-bit arches.
>  
> > I'm sure the X.2 API was very well thought out, I'm just a little surprised
> > at the kludges HURD is forced to consider due to the L4 API.  I'd like to
> > see what I'm missing.
> 
> I am not sure something fundamental would change even with the 64 bit
> interface.  Surely the race would become much harder to exploit, but
> probably still possible (I only did a quick calculation).  Now, if you give
> me timer resolution for the version id part, I would be happy, but that
> would require 64 bits for the version part alone (thus 96 or more bits for
> the whole thread id).
> 

It would still be worthwhile to think about using the PID for that. I'm always
worried about lots of global state. It tends to be not cleaned up and cause
resource leakage :(

Thanks,

p2.