Hi Scott, Scott <cheesy4poofs@cox.net> wrote:
I grabbed the code in boost CVS about 2 weeks ago. Should I get latest again?
No, that will do.
the client, that's probably acceptable. But for the server we really need multiple threads. Is it okay for each thread to create it's own io_service to solve this problem?
Yep, that's a perfectly good server design. You simply use some "load balancing" technique like round-robin to allocate incoming connections to io_service objects. (Yes, it is ok to have the acceptor and the socket being accepted on different io_service objects.) Depending on what else the server does, another approach might be to use a single io_service and single thread to do all I/O related work, and use another thread pool (possibly using another io_service) to perform the work that really needs multiple threads.
So, if I understand correctly, the UI should *not* be using the socket class because we spawn a background thread to receive data on that socket?
Yep. Basically the approach Martin suggested is the one to use. So, in the client: - Spawn a background thread to call io_service::run() - When data arrives on the socket post it the GUI using a windows message - When you need to initiate an I/O operation, post a function object to the background thread by using io_service::post(). For the server, you can: - Use one thread per io_service object to call io_service::run(). - Allocate connections to io_services e.g. using round robin - When you want to initiate an unsolicited send on a particular connection, post a function object to that connection's io_service object. or: - Use on io_service object for all I/O, and another for managing a thread pool. - Use io_service::post() to send function objects between the objects that are associated with each io_service. Cheers, Chris