<[EMAIL PROTECTED]> wrote:
> > 2) Does anyone have suggestions for a solution that will be cleaner and
> > won't take man-months to implement? [Which is the redeeming quality of
> > what I've got - it took me two days to zero in on a very workable
> > solution.]
>
> Have you tried the linuxthreads port lately? With linuxthreads, each
> thread is an rfork()ed process, which means that blocking on file I/O
only
> blocks the thread that attempts the I/O. There are various
> advantages/disadvantages between libc_r and linuxthreads, but you may
find
> linuxthreads to meet your needs at the moment.
That's being tested in parallel. The main issue with LinuxThreads is that
we'd go from running ~25 processes on this server to running ~800.
> > 3) Is anyone working on something I might leverage off of in this area?
> > [For instance, a select()-based interface to async I/O? Or support for
> > blocking disk I/O in select() and read()?]
>
> Though not ideal, it seems to me that using asynchronous I/O will work
> reasonably well inside libc_r. If there weren't plans to build a much
more
> scalable threads library than what we currently have, this modification
> would be high on my priority list.
I've been reviewing the async I/O stuff, but as far as I can see you can do
all async I/O and use aio_suspend(), or do all select-based I/O, but you
can't do both. libc_r is implemented around select-based I/O, so if an
aio_read() is dispatched, how do you catch completion?
[The only way I've thought of thus far would be to have a signal raised at
completion, resulting in tens of thousands of signals per second in this
case, which seems pretty harsh. Even so, I'm still thinking about this
option.]
Thanks,
scott
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
