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