I'd like to know if there are any plans to support one of these two
concepts in Linux:
(1) Thread local storage. It would be perfectly okay if this were a
single pointer that could be read/written for the current thread. If
more values are needed, it's no problem to attach a larger memory block
to this pointer.
(2) 1-based IDs for the threads belonging to a process (in addition to
the system-wide unique process IDs).
I'm currently trying to port an OS2/Win/Dos Delphi-like Pascal compiler
to Linux, and the absence of these concepts makes the port somewhat
difficult. I was able to emulate thread local storage, basically by a
mapping from PIDs to TIDs. This mapping is a bit slow, but since TLS
variables are seldom accessed, it works.
Unfortunately, for implementing exception handling I need a faster way
to access an exception handler chain for the current thread. It needs to
be fast because try...except...end staements occur every few lines of
code (at least in my code). 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. This is *very* fast, of course, but I guess it's not acceptable
for Linux, because it's i386-only (on the other hand FS and GS are quite
unused in i386-Linux). But what about one of the above concepts?
I'm surely not the only one who could use the two additional system
calls needed for (1). It would be handy for Free Pascal, too, I think.
The Wine authors should be very happy to see such a thing. It would also
speed-up existing thread libraries that make use of thread local
storage. And I'm sure that Borland will ask, too, once they start the
Delphi port. :-)
Bye,
Joerg
-
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/