What's wrong with user space solutions here? The normal approach is to
put that pointer on the stack rather than requiring a system call to
access it. It's faster, and it keeps stuff out of the kernel where it
belongs (since by far the vast majority of programs don't use TLS). So
just use pthread_*specific and be done with it. No problem there.
> (2) 1-based IDs for the threads belonging to a process (in addition to
> the system-wide unique process IDs).
What do you mean by 1-based? Do you mean that you want to require that
the first thread in a process always has TID 1? That's pretty kuldgy, and
very non-portable if you actually use it. If you need 1-based ID's, use
TLS and a mutex-protected global variable and have threads allocate their
process-local ID at startup and then increment the counter.
If, OTOH, you just want thread IDs (unspecified opaque handles) in
addition to process IDs, I am actually working on a patch that revamps a
lot of stuff in terms of thread vs. process right now, although "working
on" is used loosely since I've been busy and haven't touched it in a week
now. :( (BTW, this is not an invitation to re-open the somewhat stale
discussion of whether this is a good idea. I'll resume that dialog when I
have benchmark numbers and concrete results to draw from.)
> For the other platforms, as well as for Delphi itself, there's a simpe
> solution: The FS selector points to a thread information block whose
> first longword points to the head of the handler chain. The OS ensures
> that FS has the correct value for each thread.
I doubt that the kernel really does any screwing around with the values of
registers for the context. If so, I've lost a lot of what respect I
previously had for any of these operating systems. More likely, the use
of FS for that purpose is a convention used by the program, and the kernel
properly context switches, without caring what you're using your registers
for.
Actually, though, I think using a data block at the top of the stack for
this purpose is a better idea. The stack segment already exists, and is
already set up to be different for each thread.
> (on the other hand FS and GS are quite unused in i386-Linux)
You don't know that. You mean that the *kernel* doesn't use them.
Chris Smith <cd_smith@ou.edu>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/