LinuxThreads replacement

[Terry Lambert]

Petri Helenius wrote:
> >The general answer is "kqueue is your friend".  8-).
> 
> >One thing that is very helpful to do is to seperate out the flags
> >and hint arguments to KNOTE(), and then pass the user void argument
> >through to the knote() code.  Doing this is very handy, besides
> >enabling you to raise maxproc higher than the point where it
> >collides with the hints bits, I mean.
> 
> My large fd_set argument was actually targeted towards user space
> processes using existing interfaces. Where the viable options seem to
> have large select´s and do work based by spinning the descriptor set
> or have a thread block on the read on the descriptor.

I understood that; but kqueue has been around in FreeBSD as
an existing interface for longer than libthr or libkse.  By
rights, it's a much more "existing interface" than threads
are.  8-).  It's also the same in FreeBSD, OpenBSD, and MacOS
X.  I don't know if NetBSD has it or not; they don't have the
man page up yet, if they do.

You could also use poll(2), which gets around many of the
major complaints about select(2).

Actually, select(2) is an excellent example of an interface
that's going to be a holy terror to make thread safe against
the close(2) race.  Basically, it will need to hold a reference
for the entire fd table during the select, and it will have to
deal with the possibility of another thread closing and then
reopening a given individual descriptor after the first pass
through selscan(), but before the second pass.  Otherwise it's
going to be able to return false positives to user space, and
potentially cause a blocking call to be made which will simply
hang the worker thread making the call.  Enough of those, with
a set of worker threads that's smaller than the total number
of open fd's, and you're server becomes totally unresponsive
to further requests because all your worker threads are wedged.

Short of non-blocking I/O, the only thing you could do is deal
with implementing the Sun-style cancellation-on-close.

-- Terry