From: Dave Moore (jdmoore99_at_[hidden])
Date: 2005-12-20 06:45:17
> Currently AFAICT in order to use the async operations asio requires a
> model which allocates a new handler for each message received. This
> might be fine for many situations where those handlers will change from
> message to message. But for my use case I have only one handler that
> needs to get called for *any* message that comes in. In the asio case it
> means that for each message I received it would: remove the handler from
> the demuxer map, call the handler, which would do my custom parsing and
> routing, and push a new async_receive of myself (which creates a new
> handler object and inserts it again into the demux map). This is clearly
> suboptimal, and will result in considerable performance degradation. To
> refer to some concrete code, one can look at the Daytime.6 tutorial
> which does basically that procedure.
In practice, I tried out asio on Windows using the iocp implementation
with the "same handler every time" pattern of usage, and was quite
happy with CPU utilization on a 100 Mbit/s peak multicast stream (1000
-> 1500 bytes/message).
I expect that there may be some gains to be had, especially in the
epoll/kqueue based reactor implementations to allowing a user to
"preregister" a handler. Maybe there could be overloads of the
asynch operations that accept a pre-bound handler?
However, as I'm sure you know, there will always be some "Per I/O
operation" structures involved like the buffer, etc. It's pretty
common on IOCP servers to post several asynch reads on the same
socket, to avoid queueing and extra copying.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk