Boost logo

Boost :

From: Giovanni P. Deretta (gpderetta_at_[hidden])
Date: 2006-02-07 09:48:45


Stefan Seefeld wrote:
> Giovanni P. Deretta wrote:
>
>
>>>If the system has data ready to be read for that device, which reference
>>>should it dispatch them to ?
>>>
>>
>>Well the system does not dispatch readiness messages to handles, but you
>>register an handle with a callback to receive notification.
>>If you register multiple handles, all of them get the notification.
>
>
> That doesn't make much sense to me. Assuming an underlaying 'select()',
> I register file descriptors, not handlers, with a callback.
>

I said handle, not handler. An fd is an handle. In select you do not
register callback but you get the list of reay fd and call the callbacks
your self. But if you use posix aio or O_ASYNC(linux only), you may a
posix realtime signal that will call your registered callback.

> And even if that callback would itself call multiple functions, how
> much sense does it make to let them all read from the device ? They
> would all need to coordinate so they see all the data they need.
>

Well you do not need to coordinate to read/write from datagram socket.
Only one will get the incoming datagram and all datagrams will be sent.

>>Anyway, even if you have multiple copies of an handle, you should'n use
>>more than one at once expecially from multiple threads and expecially
>>stream handles (actually using the same datagram socket or accept socket
>>from multiple threads should be fine)
>
>
> Exactly. My point was really that I think making streams non-copyable
> would prevent such design errors, or at least, would make them harder
> to do. :-)
>

And I completely agree with you. But I also understand that there are
use case where having two references to the same device is useful (even
if you use only one for I/O). May be the second reference is used for
setting options, or just watch state. May be copying is used as a simple
alternative to moving (copy a to b, destroy a and use b from now on).

-- 
Giovanni P. Deretta

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk