Date: Tue, 19 Oct 2004 20:19:31 -0700 From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> To: "Ronald F. Guilmette" <rfg@monkeys.com> Cc: Andre Oppermann <andre@freebsd.org> Subject: Re: aio_connect ? Message-ID: <20041020031931.GP22681@funkthat.com> In-Reply-To: <74506.1098231543@monkeys.com> References: <41757F72.A36AD263@freebsd.org> <74506.1098231543@monkeys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ronald F. Guilmette wrote this message on Tue, Oct 19, 2004 at 17:19 -0700:
> I would just like to be able to write network clients and/or network servers
> using the kind of radically different programming style that the aio_*
> functions (with their signal-generating asynchronous interrupt capability)
> would seem to permit one to use.
>
> Basically, I have a mental model of how asynchronous events (in particular,
> various kinds of I/O completion events) really _should_ be handled. And
> the mental model I have has nothing at all to do with any kind of synchronous
> polling (which I view as inherently ugly and typically inefficient, both
> from the point of view of machine cycles, and also, perhaps more importantly,
> from the point of view of code clarity and straightforwardness, or lack
> thereof).
>
> Note that select(), poll(), and even kqueue()/kevent() are really all just
> different ways of doing _polling_ for a set of events. The kqueue/kevent
> stuff is definitely more efficient and more flexible than either select()
> or poll(), but at base, it is still just a different interface to a kernel-
> implemented polling mechanism. And as I have said, I simply do not like
> polling. Never have, and never will.
Sorry, but there is nothing in FreeBSD that will let you program in the
method you would like to do... I do agree with you that there are
many improvements that can be made.
Also, going aio_ as implemented in FreeBSD will be guaranteed to perform
worse than kqueue/kevent.. This is because aio_ requires a kernel thread
to wait for you instead of your process context.. Currently we are limited
to only executing 4 aio_ events at once.. This can be increased, but will
incure a stack for each additional thread you want to run...
FreeBSD's kernel is inherently syncronous... This will prevent you
from impelmenting what you want.. There is no way to have out standing
io for multiple file descriptors... The reason kqueue/kevent works
with sockets is that the sockets buffer data, making it work... if
this wasn't the case, it'd be much less efficent..
To handle what you want to do, we would need to completely rearchitect
the FreeBSD kernel to make more things asyncronous.. Some subsystems
are getting better at this (like geom), but Unix has historicly been a
syncronous system... So there is a lot of legacy code that will make
this more difficult...
Going async can improve things, and with it, makes implementing a sync
interface easy on top of it...
So the short of it is, no, FreeBSD at a low level does not support
it...
Now, I know this isn't what you want, but I usually make my kevent
use appear as if it's async... I use the udata pointer point to a
struct which starts with a function pointer... Then when I get events
back from kevent, I just have code that loops over the events, and calls
the associated function pointer.. simulating a signal...
Now that kqueue has been locked, it shouldn't be too hard to use
threads to create another thread and run the function in a thread, or
using cv's or something similar to wake up other threads... To
prevent multiple threads from executing, you can mark the events ONESHOT
which means that they'll be removed once returned to kevent... It
also means you could have multiple threads asking for events from the
kqueue w/o getting duplicates...
Hope this helps...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041020031931.GP22681>