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@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/libdispatch-dev

On Sep 1, 2010, at 10:09 AM, cee1 wrote:

2010/9/1 Robert Watson <robert@fledge.watson.org>

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. Do we need some APIs like putting a set of sources in a group, and then can suspend/resume them all?

I don't see why we should. GCD would end up implementing the same trivial code the end developer would: a few lines of code wrapping a dictionary (a.k.a. hash-table / associative-array) or an array of sources.

Also libdispatch will not remove/disable a kevent associating with suspending sources, implementing that feature may incur some overhead(Since we need check all sources associating with a kevent).

If that ever becomes a problem in practice, we can change the code. davez