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.
Regards,
Dave