[libdispatch-dev] I missed the intro message ;)

Matt Wright matt at sysctl.co.uk
Sat Sep 12 04:12:15 PDT 2009

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


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


More information about the libdispatch-dev mailing list