From: Don G (dongryphon_at_[hidden])
Date: 2005-03-29 10:16:59
Thanks for the reply! Please see below for my responses.
--- Jonathan Wakely <cow_at_[hidden]> wrote:
> How the kernel chooses to implement the aio system calls is an
> implementation detail - it certainly doesn't require use of
> Boost.Thread types! I think what Robert was saying is that an
> application can use POSIX aio without ever having to use or
> know about POSIX threads.
But if it calls your callback on a thread other than main, you do
care and need to know that detail. If the callback is called on the
main thread, that thread either has to cooperate or for signals
(again) be prepared to handle the special execution state inside the
> You and Don seem to be requiring that the application
> explicitly create and manage threads. Several people have
> suggested they'd like to use some form of AIO without having
> to use threads.
In the "Asynchronisity" thread, I suggest a mechanism that has
certain thread-safe properties, but the user need never create a
That being said, I am proposing the the network layer (not the
application) create and manage I/O threads. The callbacks it makes to
the application would occur in those threads, but by using a
technique like bind_async_call (see the "Asynchronicity" thread for
details), the callback to user code can be delivered on the one and
only thread that the user knows about.
In pseudo code:
int main ()
network::ptr net = ?; // create the network object
st = net->new_address("foo:1234")->new_stream();
nx.pump(); // callbacks go until nx.close() is called
void on_connect ()
st->async_read(buf, sizeof buf,
void on_read_done ()
Notice that all this is done inside main(). The user, however, must
cooperate to deliver the async messages (the nx.pump() call). But
this level of cooperation is required for most async mechanisms on
I hope this clarifies what I am proposing.
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk