[libdispatch-dev] libdispatch for Win32

[DrPizza]

> Is there a reason for you not using the readily ported libpthread_workqueue of Mark Heily? By using
> the older style threadpool you can achieve a broader compatibility as windows xp still seems quite familiar among users.

My main reasons for using the new threadpool API:
1) I actually did the work a year ago; I then went on holiday and on my return got distracted by other projects. At the time, I could find no reasonable Win32 implementation.
2) It can be used robustly, whereas the old one cannot; the old one provides no way of properly handling out-of-resource situations.
3) It allows multiple pools per process, which allows libdispatch's pools to be relatively isolated from any others that the application might create. This seems to reduce the possibility of surprises.
4) The old threadpool API lacks any effective way of tidying up, in particular preventing callbacks from safely performing such tasks as unloading the DLL they are running from, and having no way to ensure that every callback is safely executed or deallocated.
5) There did not seem any obvious way to implement e.g. pthread_workqueue_removeitem_np using old-style threadpools.
6) Timer queue timers have no leeway facility.
7) The first project that I wish to use GCD in is already incompatible with Windows XP, so compatibility with that decade-old platform was of no value to me.

The new threadpool API seems to me to be a much better basis for development.

That is not to say that the old API has no merits:
1) It's much simpler
2) BindIoCompletionCallback is a nicer mechanism; new-style threadpools require StartThreadpoolIo to be called prior to every single overlapped I/O operation, which I find unacceptably invasive.

> Did you re-implement your own version of kqueues or completely exchange the kevent etc. calls
> within your source code? DISPATCH_SOURCE_TYPE_OIO sounds interesting, as Mark and I already
> discussed a similar solution "as the way to go" on windows.

I have replaced kqueues with an I/O Completion Port mechanism. I actually retain 'struct kevent', because it's fairly thoroughly embedded in the dispatch_source mechanics, and is useful simply as a tuple of information relevant to each dispatch_source; there seemed little value in replacing it with something neutral.

> I have to disagree. By using RegisterWaitForSingleObject on a timer handle you can
> easily achieve similar behaviour using the "old" thread pool api without needing an
> additional manager thread.

If I am to retain the overall form of current libdispatch--which means abstracting away the true threadpool API and instead calling pthread_workqueue functions--then I am disinclined to write code that directly uses the underlying threadpool through the back door.

And if I were to strip out pthread_workqueues entirely then I would not want to use RegisterWaitForSingleObject due to my aforementioned dislike for the old threadpool API.

> That would be interesting although I hope we can merge our efforts within the near
> future.
Certainly, there's no point in duplicating effort if we decide to take similar paths.