[libdispatch-dev] Updates regarding the status of libdispatch on Windows

DrPizza DrPizza at quiscalusmexicanus.org
Mon May 9 06:47:45 PDT 2011


> 1) How to specify the exact difference between a shim and an implementation
> for a specific platform? Both is the same to me, possibly differing only in
> the amount of code that is needed ...

Here's the difference, as I see it. shims should be small libdispatch-specific 
wrappers to hide certain platform differences. I think if you take a look at 
the shims in the mainline tree, the functions are named _dispatch_xxx.

In contrast, the things I put into the platform tree were Win32 ports/wrappers 
that weren't libdispatch-specific. Stub POSIX headers, pthreads, and of coures 
pthread_workqueues. It's not just that these are larger pieces of code; it's 
that they're not thin libdispatch-specific wrappers.

> 2) In order to increase the overall maintainability it would possibly be a
> good idea to do some layout changes to the overall source code of libdispatch
> regarding platform specific (may it be Windows, Linux, Darwin, Cocoa, Qt,
> WndProc,...) implementations as is common practice within other projects. The
> question is wether this is welcomed by the upstream maintainers. My
> suggestion for a layout would be:

I'm not sure if it's feasible to break out every component of the integration 
into a separate tree, since the call-outs from dispatch into the windowing 
toolkits need to be relatively integrated. But if it can be done effectively, 
it would certainly be a good thing to do--keeping Cocoa (Qt, WndProc...) 
compatibility out of the main codebase would probably make it easier to keep 
everything aligned.

> As a side effect we'd have to make a decision regarding kevents and the
> pthread_workqueue api. We'd either need to define a new interface and move
> the usage of the afore mentioned into platform or make sure to use
> implementations such as libkqueue (an implementation I consider quite well
> designed for cross-platform support) already providing the abstractions we'd
> need to implement by hand once more otherwise. Another possibility could be
> to move the *_kevent.c implementations completely into the platform
> hierarchy, eradicating at least the need for kevents.
> Our overall goal should be to have a src/core folder that is as clean as
> possible...

I looked at that, but struct kevent is quite thoroughly embedded into the 
codebase, and moving away from that will probably be much more trouble than 
it's worth. If starting from a clean slate then perhaps one might not use 
struct kevent, but it's there now, it holds all the data that's needed, and 
so it's probably there for good. To me, this would argue against trying to 
move the *_kevent.c files out of the main tree.

Peter


More information about the libdispatch-dev mailing list