From: Hu Xinwei (huxw_at_[hidden])
Date: 2002-11-25 09:51:17
>Eric Woodruff wrote:
>> * Support for Event-Driven and Blocking sockets This one should go
>> without saying. The event-driven support can trivially be provided
>> in the pure socket interface and easily created using tools like
>> boost::signals or boost::function.
>> ** Thread Pool For event-driven sockets, a thread per socket can
>> sometimes be wasteful, so there may be support for using a thread
>> pool that monitors for events on the sockets in an application.
>And I think it would be really important to provide a clean
>interaction model between the socket library and the thread library
>and a clean solution to the problems that keep on coming up again and
>again when doing socket programming. From the top of my head:
>- How to interupt a thread waiting on some socket event (synchronous
>and asynchronous) from another thread?
IMHO, I dont think such a mechanism is needed.
>- How do you wait for more than just socket events? Thread conditions,
>window messages, ...
I think that is not a problem too. We at such a condition, should have 2 threads, one to block on socket, and another handles all other messages from os, other processes...... If you are really intersted in the thread conditions, you have to poll them by yourself, because there is no such a generic mechanism on every platform and it is rearly used.
IMO, thread model is used to simplify your design. One thread should take one resposibility and one only.
>I'm sure there are other things.
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk