Implement OSX support using GCD

[trevnorris]

AFAIK the versions of OSX currently supported also support GCD. I think writing __APPLE__ support using GCD would help solve problems like forcing serialized file system writes.

Granted I don't even own an Mac and won't be the one doing this work, I think this is worth consideration.

[saghul]

Isn't this a duplicate of #686? If not, please can you detail what problems would GCD solve here?

[txdv]

Looks like a nice set of APIs for true asynchronous file write and reads for MacOSX.

Are you planning on implementing this in libuv @trevnorris? Or are you just posting this with the idea that someone else has to do it?

[trevnorris]

@saghul Partially yes. But it also would allow greater enhancements. For example, I believe it would be possible to remove the need for a thread pool on OSX. From the docs:

Blocks submitted to dispatch queues are executed on a pool of threads fully managed by the system.

@txdv Haha. Hell no. I hate Apple products. But, even more, I like to see code improved.

[saghul]

@trevnorris Well, the problem here is that if we switch to GCD we would loose platform consistency, exactly because the threadpool is managed by the system. So I'd like to see what the exact gains are before someone jumps to implement it blindly.

[indutny]

Wait a sec, guys. Will it be possible to send events back to the libuv event loop? It should be quite easy to dispatch new events, but replying back may be really complicated.

[txdv]

So linux has no AIO for files without O_DIRECT, Windows has IOCP and MacOSX has Grand Central Dispatch.

I'm freaking sad right now.

[trevnorris]

I know little about the Windows implementation, but I'm sure @piscisaureus
has told me that Win doesn't have a thread pool. So how does that fit in
with platform consistency?

[trevnorris]

@indutny The GCD uses a streams type interface for fd's, and handlers are passed to alert when the operation is complete. Take a look at this: https://developer.apple.com/library/mac/documentation/performance/reference/gcd_libdispatch_ref/Reference/reference.html#//apple_ref/c/func/dispatch_write

[saghul]

As of right now there is a single threadpool implementation which all
platforms use.
On Aug 14, 2014 1:10 AM, "Trevor Norris" notifications@github.com wrote:

I know little about the Windows implementation, but I'm sure @piscisaureus
has told me that Win doesn't have a thread pool. So how does that fit in
with platform consistency?

—
Reply to this email directly or view it on GitHub
#1417 (comment).

[indutny]

@trevnorris aaah, so you want it to not use kqueue at all. I wonder, if internally it is still using kqueue for all that stuff. This is what normally OSX does even with mach ports and rest.

[aktau]

The Grand Central Dispatch code is open source: http://libdispatch.macosforge.org/

Also, as far as I can remember, OSX implements POSIX AIO natively in the kernel (as Linux has wanted to do for quite some time, to adapt Linux AIO to POSIX AIO, this still hasn't happened). So both should be good options, fwiw. Apple is closing the kernel more and more with each release, so it gets more difficult to check*.

• Not closing the existing parts, but moving them out of the kernel and into extensions where they don't have to open-source it, since Mavericks, POSIX threading support was outsourced to a kext. One can still learn a lot through disassembling OSX's various libc dylibs though. Nothing much has changed, they just de-opensourced it.

[saghul]

I'm closing this now. Feel free to explore the benefits of using GCD and reopen at libuv/libuv with some numbers so we can consider what to do.