Hey :) On 12 Sep 2009, at 10:15, Robert Watson wrote:

I've got libdispatch building on FreeBSD, and am currently debugging it, so I can speak a bit to the dependencies I've identified that aren't (yet) in FreeBSD. This is probably pretty similar to the list of things in Snow Leopard but not Leopard:

Wow you've been busy. I've barely had time to sit down and look at the source since it was released :).

- libdispatch_init is invoked directly by the libsyscall bootstrap in libSystem. At least on FreeBSD, we can't just switch to an attribute constructor because of the way rtld performs locking around library init routines, so I'm pondering this still. This is an issue for a Leopard port also.

I have this in my own port too. For ease-of-bringup I opted to have the users of my library call some initialisation calls at the very start of their program. Specifically, one to start up the manager and worker threads and then one to insert the main queue on the main thread's runloop.

- libdispatch includes support for monitoring Mach ports. Not in scope for me on FreeBSD, so I just added a HAVE_MACH configure test. Not an issue for a Leopard port.

- libdispatch uses Mach semaphores. In FreeBSD, I've substituted POSIX semaphores. I've run into at least one issue doing so, as libdispatch maintains parallel state and appears not to propagate an initial declared 'value' to the Mach semaphore. Once I understand the problem better, I'll post a more specific query for the Apple folks. Not an issue for a Leopard port.

Yeah some of the Apple BSD specific stuff is gonna bite on all OS's. I think FreeBSD will be the easiest ride as you'll already have (most) of kqueue. Having completely missed kqueue in my implementation, I was thinking of going back and adding it until we've got libdispatch to the point where it could replace my library in my own applications. <snip>

- libdispatch uses the pthread_workqueue primitive by default, but can also manage its own thread pool using portable pthread primitives. For the FreeBSD port, we'll do the latter for now, but we have an agenda item for the FreeBSD developer summit later this week to talk about GCD, and in particular, pthread work queues. For a Leopard port, you should just be able to use the "pure" pthread version of the code, which configure picks up in the auto* build system.

Yeah. I hadn't come across pthread_workqueue in any shape or form yet. So I'm going to have to look that up to understand what it does.

- libdispatch relies on EV_DISPATCH and EV_RECEIPT, which don't (yet) appear in FreeBSD's kqueue code. I need to look at the SL xnu bits some more and decide on the right approach, but likely merging them back to FreeBSD is the way to go. EV_RECEIPT is in Leopard, but EV_DISPATCH is not, which may be an issue for the Leopard port. This isn't an issue I fully understand yet but I can probably comment more once I've done a bit more reading.

- libdispatch relies on EVFILT_USER to post events to itself via kqueue from one thread to another. This also needs to be merged back to FreeBSD, and isn't in Leopard, so will be an issue. There are probably workarounds that don't involve adding these to the kernel (perhaps using a pipe to do a loopback notification, or something more elegant?) but the cleanest solution is to have the kernel functionality. I guess Apple folk might (or might not) be able to comment on the chances of this appearing in a future Leopard update.

Yeah I saw this much when picking through the source. I figured the same deal about pipes, wouldn't be that gruesome a hack and would stop the code relying on a particular revision of your kernel. I'm very keen with my implementation for it not to need anything done by the user. Kext's and kernel upgrades are off the board for me and I'll use my implementation in my own apps until libdispatch can drop-in replace it. Having an application that needs root access on first execution is not cool ;)

- libdispatch blocks routines won't work on FreeBSD currently; FreeBSD builds fine with clang/llvm, but some work on the C runtime will be required. In particular, it would be good to have the runtime blocks support in FreeBSD's libgcc, I suspect. Non-blocks will apply to Leopard as well, but Apple has already carefully ifdef'd all the blocks parts.

You can get blocks if you wish. The PLBlocks compiler (http://code.google.com/p/plblocks/ ) is a Leopard/iPhone compatible GCC 4.2 that has had the blocks patches backported. Again, I would imagine it wouldn't be overly hard to port these patches to FreeBSD's compilers. Blocks really do make GCD in terms of ease-of-use of the API. I don't think it would be quite as attractive if you were forced to dispatch function pointers. Part of my love with GCD is how easy it is to dispatch single use functions, things that would previously have required a function cluttering up your codebase. Code is a lot clearer using blocks to do this kind of thing.

If things go well, I should be able to post patches this weekend, but debugging the libdispatch startup process involves understanding a lot of subtle issues so we'll see. :-)

Sounds good, I suspect you'll have a lot more time to have a look at this than I will over this weekend. I'll have to work out the pieces of the puzzle I'm missing for building on SL too. Matt