1:1 Threading implementation.

[Igor Sysoev]

On Tue, 25 Mar 2003, Jeff Roberson wrote:

> I realize that many people have strong feelings on this topic.  I'm asking
> everyone up front to try not to devolve this thread into a bikeshed.
> 
> Thanks to the foundation provided by Julian, David Xu, Mini, Dan Eischen,
> and everyone else who has participated with KSE and libpthread development
> Mini and I have developed a 1:1 threading implementation.  This code works
> in parallel with KSE and does not break it in any way.  It actually helps
> bring M:N threading closer by testing out shared bits.

I'm very glad to see two kind of the kernel supported threads in FreeBSD.

> The condition variables and other blocking situations are handled with
> sig*wait*() and a new signal, SIGTHR.  There are many reasons that we went
> with a signal here.  If anyone cares to know them, you may ask.

I ask :)

> There are only 4 system calls for threading. thr_create, thr_self,
> thr_exit, and thr_kill.  The rest of the functionality is implemented in a
> library that has been heavily hacked up from the original libc_r.

I think thr_create() should have a optional capability to create a thread's
stack.  This allow to save one syscall because otherwise you need to call
mmap() or malloc()/sbrk() before the_create().

I think that thr_self() should be implemented in the user land.  It's used
in pthread_getspecific(), pthread_setspecific(), and gcc3's __thread attribute
and can be used very often and should be very cheap.

Solaris uses gs register on x86 and %g7 register on Sparc.
Linux also uses gs register on x86, other platforms implementation details
can be found here - http://people.redhat.com/drepper/tls.pdf
Win32 and OS/2 use fs register.

As far as I know FreeBSD 4.x uses gs to proc in a kernel and 5.x uses fs
for some per-CPU data in a kernel.  I think we should use one of these
register to point to the thread specific data in the user land.

> I'd like to get the signal code commited asap.  It's the majority of the
> patch and I often have to resolve conflicts.  There have been no
> regressions in KSE or non threaded applications with this signal code.

Did this signal code supports siginfo ?
FreeBSD 4.x fills zeros in the most siginfo's fileds.


Igor Sysoev
http://sysoev.ru/en/