libthr and 1:1 threading.

[Matthew Dillon]

: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.
:
:Umm Terry.. we have zero infrastructure to support this.
:
:Cheers,
:-Peter
:--
:Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
:"All of this is for nothing if we don't go to the stars" - JMS/B5

    It would be a very bad idea anyway.  If someone is that dependant
    on detecting page-fault or page-in behavior during I/O then they
    ought to be using AIO (which does queue the request), not, read(),
    or they should wire the memory in question. 

    I think I know what Terry wants... the best of both worlds when
    faced with the classic performance tradeoff between a cached 
    synchronous operation and an asynchronous operation.  Giving
    read() + NBIO certain asynchronous characteristics solves the
    performance problem but breaks the read() API (with or without
    NBIO) in a major way.

    A better solution would be to give AIO the capability to
    operate synchronously if the operation would occur in a 
    non-blocking fashion (inclusive of blockages on page faults),
    and asynchronously otherwise.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>