[libdispatch-dev] Question about event handling in libdispatch

[Robert Watson]

On Sat, 28 Aug 2010, Dave Zarzycki wrote:

> The behavior of libdispatch is: 1) Consistent with traditional Unix event 
> delivery APIs like select() and poll(); and newer APIs like BSD kqueues. 2) 
> Convenient for datagram driven protocols (such as UDP) where a packet is 
> read or not-read, but never partially read. 3) Inconsequential to stream 
> driven protocols (such as TCP), since it is practically impossible to 
> implement multiple readers/writers to a given socket due to partial reads or 
> partial writes. In other words, these clients only create one dispatch 
> source per stream to avoid the partial read/write problem, and therefore 
> they avoid the problem that you describe.

In the Apache GCD MPM, I took the approach of attaching a set of dispatch 
sources (particularly, read, write, and timers) with each socket, and then 
used a serial dispatch queue to ensure that processing of the connection's 
state machine was ordered.  Since most protocols likewise assume (effectively) 
an automata parsing symbols off the wire in a specific order, this didn't seem 
like a limitation so much as a feature.  In Apache, there was no further need 
to introduce asynchrony in processing events from the wire, but you could 
imagine doing so very easily for more concurrent applications, such as IMAP.

This seemed to work quite well -- the one real downside to the current GCD API 
is that it required a moderate amount of book-keeping in the consumer to 
handle suspending dispatch sources.  It wasn't clear to me how to make this 
better, though, and was certainly acceptable complexity compared to dealing 
with other APIs.

Robert

> 
> davez
> 
> 
> On Aug 28, 2010, at 5:20 AM, cee1 wrote:
>
>       Hi all,
> A kevent can associate with more than one source. What if:
>  1. A kevent of EVFILT_READ indicating that data is available to read.
>  2. A series of sources associating with this kevent are waken up.
>  3. One source handler fetches the data.
>  4. The rest source handlers will find there is no data available to
>     read in monitored fd.
> It seems waking up more than one source doesn't make sense here? The
> rest source handlers will simply fail to read.
> 
> 
> --
> Regards,
> - cee1
> 
> _______________________________________________
> libdispatch-dev mailing list
> libdispatch-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/libdispatch-dev
> 
> 
> 
>