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