Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-04-22 07:41:22

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

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.

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