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

Kevin Van Vechten kvv at apple.com
Sat Sep 12 22:17:01 PDT 2009


On Sep 12, 2009, at 2:15 AM, Robert Watson wrote:

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

A count is kept in user space and updated with atomic operations.  The  
general idea is to avoid trapping into the kernel except when blocking  
is required (or when signaling a blocked thread is required).

> - There are some issues with libdispatch's internal use of the  
> legacy API.  My
>  goal has been not to compile in legacy.c, and this has caused a few  
> build
>  nits so far.  The only such nit not yet resolved in the libdispatch  
> tree is
>  in the kqueue debugging server built into libdispatch.  I think a  
> similar
>  goal of non-support for legacy APIs for a Leopard port is reasonable.

Yes, there's no need to expose the legacy API.  We're working to clean  
up the last vestiges of it internally and hope to fully obsolete it  
soon.

> - libdispatch uses Apple's userspace malloc zone API; for FreeBSD  
> purposes,
>  I've made it a simple wrapper around malloc, which is functionally  
> correct
>  and given jemalloc, possibly as performant.  I'll need to benchmark  
> this
>  later.  Not an issue for Leopard.

The purpose of the malloc zone API was to segregate the "dispatch  
continuation" allocations into their own zone.  Since these are  
allocated frequently to support dispatch_async, and are always the  
same size, we figured putting them in their own zone would avoid  
fragmentation in the general heap.

Due to the fixed size nature of these allocations, someday we hope to  
evaluate other allocation strategies that may yield better performance  
than a general malloc zone.

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

The general idea behind EV_DISPATCH is to disable an event source  
immediately after delivery of an event.  It's a similar idea to  
EV_ONESHOT except the registration remains and it's possible to  
EV_ENABLE it again.

I haven't thought about the issue in depth yet, but it may be possible  
to use EV_DISABLE immediately after the receipt of certain events to  
simulate EV_DISPATCH.

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

Using a pipe is probably the right solution when EVFILT_USER is  
unavailable.  Another possible technique is to use an EVFILT_TIMER  
with a small enough fire date (i.e. 1ns) so as to be functionally  
immediate.

Kevin



More information about the libdispatch-dev mailing list