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

[Marius Zwicker]

> Overall, I've tried to keep the source tree looking as close to the 
> original
> as was practical. The major departure is the creation of the platform
> hierarchy [10], which is where the major support infrastructure 
> required for
> Win32 is kept. This includes Win32 versions of certain portions of 
> pthreads,
> including TLS storage with TLS destructors (an egregious oversight 
> from
> Win32), and a pthread_workqueue wrapper for native Win32 threadpools. 
> There
> are also Win32 versions of POSIX semaphores, though the semaphore 
> class uses
> Win32 semaphores directly now anyway.
>
> I'm not averse to some alternative layout, but I don't think sticking 
> this
> stuff in the shims directory is the best place for it; the pthread,
> semaphore
> and pthread_workqueue wrappers, in particular, are far more 
> substantial than
> mere shims.
>
> Regards,
>
> Peter

So there are two problems arising to me:

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 ...
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:

  + dispatch (includes)
  + platform
    + windows
    + linux
    + darwin
    + include // some directory containing the declarations of the api 
to be implemented on a new platform
  + integration // better named 'toolkits' ?
    + cocoa
    + qt
    + windows
  + src // possibly renamed to 'core'
  + man
  + config
  + m4

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...

It certainly is a bit weird to have this discussion after (!) doing all 
those implementations on windows and linux... but hopefully it is not 
too late yet.

Awaiting your comments,
Marius