Re: libthr and 1:1 threading.

Jeff Roberson wrote:
> On Wed, 2 Apr 2003, Terry Lambert wrote:
> > Peter Wemm wrote:
> > > No.  It gives the ability for a thread to block on a syscall without
> > > stalling the entire system.  Just try using mysqld on a system using libc_r
> > > and heavy disk IO.  You can't select() on a read() from disk.  Thats the
> > > ultimate reason to do it.  The SMP parallelism is a bonus.
> >
> > Bug in FreeBSD's NBIO implementation.  A read() that would result
> > in page-in needs to queue the request, but return EAGAIN to user
> > space to indicate the request cannot be satisfied.  Making select()
> > come true for disk I/O after the fault is satisfied is a seperate
> > issue.  Probably need to pass the fd all the way down.
> 
> Please quote the standard that defines this behavior.  This is entirely
> counter to everything that I have ever read on the subject.

There's no "standard" that specifies this behaviour, but there's
code that defines it.

I believe this is the way BSD 4.2 and 4.3 worked.  You could maybe
as Kirk about it, if you don't want to believe me on it.

The thing that broke it was the switch to the vnode abstraction
seperation from the fd, going to a vnode-based pager, and the
switch to a unified VM and buffer cache.

At that point, the non-blocking I/O flags weren't available to
the pager to enable it to make a decision on whether or not to
block the process pending completion of the paging operation.

SVR4 and Solaris both support doing this; I used it to great
effect in SVR4.0.2 in 1994 for NetWare for UNIX, at Novell.


It's pretty clear from just thinking about the idea that it
makes sense, if you are using non-blocking I/O, to start the
operation and return early.  It's the same effect that's
exploited by having a seperate context to use for each blocking
operation.

-- Terry