[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