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