[libdispatch-dev] libdispatch on VS 2008 and VS 2010 64bit
DrPizza
DrPizza at quiscalusmexicanus.org
Sun Jun 19 18:20:04 PDT 2011
> This would probably break the DISPATCH_SOURCE_TYPE_MACH_SEND and
> DISPATCH_SOURCE_TYPE_MACH_RECV source types, since they share the same
> codepath. You would have to add something like a 'ds_is_or' bitfield and do:
>
> } else if (ds->ds_is_or) {
> dispatch_atomic_or(&ds->ds_pending_data, ke->data);
> } else {
> /* Mach send or recv */
> dispatch_atomic_or(&ds->ds_pending_data, ke->fflags &
> ds->ds_pending_data_mask);
> }
I don't think we need an extra flag. We can simply inspect ke->filter to see
if the type is DISPATCH_EVFILT_CUSTOM_OR.
It's not actually clear to me that the existing behaviour is entirely correct
for DISPATCH_SOURCE_TYPE_MACH_RECV. EVFILT_MACHPORT sets struct kevent::data
to the mach msg_size. fflags should come back empty, so what's the point of
or-ing it?
Perhaps the else if at [1] should be a plain if?
> Moreover, GCD has already shipped with the implicit limitation of 32-bit
> masks in MacOS 10.6 and probably in 10.7. If you extend the mask to 64-bits
> now, that breaks backwards compatibility. Since there are very few cases
> where a 64-bit mask would be useful, the cost of breaking compatibility
> outweighs the benefit.
Well, no--GCD has shipped with a bug wherein the actual behaviour differs
from the documented and naively expected behaviour! Neither the documentation
nor the API carry any indication of a 32-bit mask--that's why the mask is
an unsigned long, after all.
Peter
http://libdispatch.macosforge.org/trac/browser/trunk/src/source_kevent.c#L613
More information about the libdispatch-dev
mailing list