1:N threading

[Daniel Eischen]

On Thu, 3 Apr 2003, Terry Lambert wrote:

> Daniel Eischen wrote:
> > Libc_r will go bye-bye.  The KSE library will give you 1:N
> > as long as you don't use pthread_setconcurrency() and don't
> > create any PTHREAD_SCOPE_PROCESS threads.
> 
> 
> I think that maybe you need to get over the "fear factor" here.
> 
> Specifically, it's probably time to commit a "libkse", the same
> way that Jeff committed a "libthr", so that it doesn't directly
> replace "libc_r", and leave people hanging over a cliff if it
> has a bug.

There already is a "libkse" committed.  It's in src/lib/libpthread.
It sorta works from what I understand (so far I've only
run my locally modified version).

My changes haven't been committed yet because I at least want
to get it to the point that it can run most of the test programs
(to be on-par with the current libpthread).  David, Julian, and
myself are working out some issues with signals, but that isn't
currently hindering my progress.

I am getting closer to be able to run some of the more complicated
test programs.

> Better to take an approach that doesn't piss people off, but gets
> the code to a wider audience.
> 
> Is this a possibility?  The only thing that seems screwed up is
> the signals processing.  Jeff's code panic's the system with a
> lock order reversal on exit processing, under some circumstances,
> but it's tolerated because it didn't outright replace "libc_r",
> and offer an alternative to "conservative" -CURRENT users.

The patches are available:

  http://people.freebsd.org/~deischen/libpthread.diffs

FYI, since this is a new mailing list, the above changes
are meant to give libpthread M:N capability.

I don't need testers; I have enough bugs that I know about
to fix.

-- 
Dan Eischen