[libdispatch-dev] libdispatch for Win32

[DrPizza]

Replying to myself...

> Rework dispatch_sources:
>   * The Windows overlapped I/O model is better than the traditional UNIX 
>     one, but doesn’t readily support:
>         DISPATCH_SOURCE_TYPE_READ
>         DISPATCH_SOURCE_TYPE_WRITE
>   * But what I do have instead is initial support
>         DISPATCH_SOURCE_TYPE_OIO (for "overlapped I/O")
>             example: https://gist.github.com/938097

It was remiss of me to fail to point out that for sockets, specifically, 
Windows does of course allow use of select(), which could be used to provide 
READ/WRITE support. I could reinstate this (though it will need to go on a 
different thread; one to dequeue from the IOCP, one to call select), but 
select() is a poor API--O(n) performance, amongst other things--so this has 
not been a priority for me.

Overlapped I/O has been my priority as it provides a uniform approach across 
both files and sockets, and unlike calling select() on FDs in UNIX, it is 
actually useful for local disks. select() called against disk FDs will always 
return immediately, because a file is basically always deemed to be readable 
and writeable (unless at EOF or similar), even if those reads and writes will, 
in fact, block. Overlapped I/O allows true non-blocking operations.

Going the other way, one could envisage a DISPATCH_SOURCE_TYPE_AIO, for 
FreeBSD's AIO. This would work in a manner broadly similar to my 
DISPATCH_SOURCE_TYPE_OIO; in fact, I think the user interfaces for the two 
could be made similar, with dispatch_source_get_data returning the OVERLAPPED 
on Windows and aiocb on FreeBSD. The big difference is that I believe that 
each and every aiocb used to perform an AIO operation needs to be registered 
with the kqueue, so there would need to be an API to perform this registration 
on a call-by-call basis, in contrast to the Windows approach where I can 
simply register the _HANDLE_ against the IOCP.

Alas, AIO isn't available on Mac OS X. I don't immediately see any effective 
way to do non-blocking file I/O on that platform, but perhaps I am overlooking 
something.

Peter