Re: libc6_2.0.106-0.1_i386.deb is released
> I'd like to give it a shot (implementing pthreads support for the Hurd
> I mean).
That would be great! I would very much like this to be as OS-independent
as possible, and to clean up and generalize the linuxthreads code as you
see fit so that we have a single clean implementation. If doing this right
turns out to necessitate changing the libpthread ABI for linux, we'll find
a way to deal.
> It seems that on the i386, it is possible to use the LDT to
> store some thread-specific data. Mach supports a per-thread LDT and
> even has an RPC interface to manipulate it.
You could do that, but I think it is simpler to start with the cthreads
approach of using fix-sized aligned stacks for threads and storing data at
the base of the stack. This doesn't implement the stackaddr pthread
attribute, but you could probably get it going faster. I have no
particular confidence in the ldt code in gnumach, since it has not been
well exercised in a very long time.
> I have to admit that I stole this idea from Ulrich (there is a file in
> the linuxthreads add-on that contains some code, but it isn't actually
> used). Nevertheless, I'll try to make things as machine/OS independent
> as possible.
It's not a new idea, and there are other variations using the x86 segment
registers besides LDT. On most other current machines (RISC), it is
canonical to dedicate a register for this.
As long as you isolate that magic in a sysdeps file, we can change it later
and for different kernel setups. (Another implementation that can be more
efficient on the x86 is to have a segment register point to a dedicated
word in high memory that the kernel changes on context switches. That
avoids changing segmentation state on the chip for every thread switch.)
I think Thomas objects to the LDT stuff because it's machine-specific hairy
(and crufty old code in mach), and I sympathize with his conservatism. But
truly sufficient pthreads support requires supporting the stackaddr and
stacksize pthread attributes, and then you cannot make universal
assumptions about stack layout. It's just the way it is.
Reply to: