Peter Dimov wrote:
Michel André wrote:
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.
Or having one thread polling one dispatcher and another one calling the other handling connections with different priority eg for one sake or another.
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.
I think the idea of a poll or an dispatcer::dispatch is a great idea and gives the opportunity to write single threaded reactive servers or clients for that matter.
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.)
Maybe this isn't strictly needed, but I imagine some isssues could raise during shutdown, if the order isn't defined.
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.
Ok. So basically net::poll should be thread safe and I could use a thread pool dispatching io events by executing net::poll in a loop. Do you envisione some way to control the threading policy for net::asynch_poll? Such as number or working threads or whatnot or should it be at the libraries discretion.
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.
Ok. And thats a fair goal thats needed. /Michel