In article <1a6101bf5bc1$4e364b20$[EMAIL PROTECTED]>,
Scott Hess <[EMAIL PROTECTED]> wrote:
> 
> I've implemented a rough fix, which is to rfork() processes which I label
> "iothreads" to handle the disk I/O.  The parent process running pthreads
> has a socketpair() to each of the iothreads.  The iothreads wait for
> requests on the socketpair, and since socketpairs can block, pthreads can
> handle them efficiently.
...
> Unfortunately, I'm concerned about using this code in production, because
> it needs a fair amount of cleanup to handle signals and administrative
> functions correctly.  For this reason and others, I'm starting a project to
> move it into the pthreads library itself.  Before I embark on that effort,
> I have a couple questions:
> 
> 1) Does this seem like a reasonable approach?  [It _works_, and well.  But
> it tastes strongly of hack.]

I think the approach is reasonable, but it shouldn't go into the
pthreads library.  It's too heavyweight for that -- too much machinery
when your average client just wants to read from a file.

Pthreads will eventually handle disk I/O better than it does now,
using aio calls or some other technique.

John
-- 
  John Polstra                                               [EMAIL PROTECTED]
  John D. Polstra & Co., Inc.                        Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to