Boost logo

Boost :

From: Michel André (michel.andre_at_[hidden])
Date: 2005-04-22 09:27:08

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

> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at