|
Boost : |
From: christopher baus (christopher_at_[hidden])
Date: 2005-12-15 13:51:17
> What I did was to have the main thread accept incomming requests, and put
> them in the queue, whereas a number of worker threads was taking these
> requests from the queue, and execute them. I don't see how this model can
> be absolutely inferior in all possible contexts.
>
I think your argument regarding the sync interface *might* be valid for
other reasons, but I want to point out that this architecture only scales
if you have an async front end that reads and writes from the socket and
parses the connection into tasks in the main thread, and then handles
these tasks synchronously in a thread pool. Say for instance a web server
which handles HTTP request pipelines asynchronously and database
connections synchronously.
If the system contains long lived connections, then you are basically only
servicing the number of connections in your thread pool, and there is a
good chance the other connections will timeout.
I do agree with Peter. If asio leads developers away from
thread/connection architectures, then it has succeeded. As with a lot of
technologies that are shiny and new, I think the industry has put too much
emphasis on threads as the solution to all concurrency problems. I think
we understand the problems better now.
Christopher
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk