Re: libthr and 1:1 threading.

Peter Wemm wrote:
> 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.

There are a couple of PROC_LOCK()/PROC_UNLOCK() pairs in
trap_pfault(), and there's the translation of the fault for
emulators, which isn't protected at all in trap(), but there's
not really any proc references which are held for a long time
in the fault handing path, at least for T_PAGEFLT.

Hmm.

The problem comes down to the vnops version of the struct fileops,
which comes down to VOP_READ which comes down to ffs_read, which
then falls down to "try get the data from the object using vm
tricks" -- uioread().

Is ENABLE_VFS_IOOPT permanently disabled?  Nope -- enabled; I
see a prototype unconditionalized in uio.h.

This doesn't look too hard to implement on a per struct fileops,
per-VFS basis; it's not like there's sleeping on a process,
rather than a vnode lock or anything; mostly everything is
marked "GIANT_REQUIRED" after a certain point.

Worst case, you could create a kernel-only thread pool in whose
context you operated, after validating credentials (obviously).


-- Terry