Michel André wrote:
Peter Dimov wrote:
This means we have one global dispatcher for the library (completion queue in asynch case). Isn't there a need to have several dispatchers to be able to group connections to several dispatchers/pollers.
You can probably guess that I think that the answer is no. ;-)
Yep ;)
Do you have specific reasons? Like interface simplicity, implementation complexity?
Simplicity, mainly. If multiple dispatchers were present, how would you use them to your advantage? The typical application loop would still consist of polling all the dispatchers. The intent of poll is to preserve the conceptual model of the current library, but allow the client to be unaware of threading issues. Single threaded clients typically have a loop that is a natural place for the net::poll call.
How do you stop the asynch polling threads started with net::asynch_poll or isn't that needed?
The library already supplies several 'cancel' functions, so something similar could be used here as well (although I've never had a need to stop a background dispatcher so I'm not sure whether this is an essential feature.)
Why should delivery of notifications from net::poll only be on operations started from that thread? This would divide threads to i/o non i/o and I won't be able to post async op from non i/o threads. Or am I missing some parts of the puzzle ;)
I see that what I wrote is ambiguous. net::poll executes the pending callbacks in the notification queue, regardless of the thread that scheduled them. The actual callback invocations are made from the thread that invoked net::poll. The idea is to eliminate the need for locking and reentrancy in single-threaded clients, not to filter callbacks based on the thread that scheduled them.