[boost] Question about boost::asio's design

From: Yingfeng (yingfeng.zhang_at_[hidden])
Date: 2008-07-06 01:12:55

I am using asio to my software and i have some design issue about asio and hope
could get your idea about it.

I plan to develop a server based on asio, which could support high concurrency
with complicated back end tasks to be provided, that is to say, when received a
request from a client, there exists a task involved with lots of disk io and
many cpu cycles to serve that request. Therefore, some concurrency design
pattern would be used together with a thread pool, such as Half-Asyn/Half-Syn or
Leader/Followers.

I have read some sources of Asio, i think the idea of using Reactor to implement
Proactor is pretty cool. Here is what I have got from the code about the working
flow:
Take asyn_receive as an example:
1. A functor of receive_handler together with the socket descriptor is added to
the read operation queue.
2. Reactor is blocked on the demulplex call such as select
3. When read is available, Reactor retrieves the read op from the read operation
queue and invoke the functor named receive_handler
4. Reactor receive the data
5. After the data has been finished reading, another event with the handler
which could be customed by users is posted to the read operation queue.
...

According to the above flow, I can see that there exist two kinds of events in
the operation queue: events to handle socket IO and events with completion
handler customed by users.

In the users' eye, the process of retrieving operation from queue and then
invoke handler is proceeded within io_service::run(), therefore a thread pool
should be binded with io_service::run(), which is just shown in the example of
Http server 3.

In the design pattern of Half-Asyn/Half-Syn or Leader/Followers, the working
flow is: after retrieving an operation from the queue, then dispatch a thread to
process that operation handler. However, in the asio's design, if I used the
threadpool to io_service::run(), then both events of processing socket IO and
completion handler will occupy the thread. I think this will cause more
threading overhead. I think it is reasonable that only one thread to process the
network IO, and other threads to process the task of completion handler.
However, it is difficult to do that in the current design.  Do you have any
opinion about my situation?  Very grateful!

Yingfeng