September 2009 - libdispatch-dev - lists.macosforge.org

I missed the intro message ;)
by Matt Wright 14 Sep '09

14 Sep '09

Hey guys, Right, despite signing up to the mailing list this morning. I managed to miss the introduction message because I had to go to work before I'd done the confirmation email ;). I'm very interested in contributing, I've had my own implementation of libdispatch's API for a week or so. Spent the morning having a little compare between how I've done mine and how yours is actually written. I don't have a paid ADC membership so much first exposure to GCD was the weekend that Snow Leopard came out, by the following weekend I was enamoured with it to the extent that I wanted to write it for Leopard. So the first thing that struck me is that it doesn't build. My first guess was that it relied on being built in the presence of the darwin sources? I haven't had enough time to have a look. I'm especially interested in the line in the project description about kernel support. Are we just talking kqueue here? Or an additional kernel module? From a personal standpoint, I wrote my implementation (http://daagaak.github.com/WiganWallgate/ ) in order to be able to use libdispatch calls on Leopard. I've several personal projects that I really wanted to use GCD in but without it in Leopard would mean moving my code to be Snow Leopard only. All-in-all writing my own version was a very entertaining weekend, even if it ends up getting dropped in favour of making libdispatch work on Leopard/iPhone/etc. I wonder if you could shed some light on what kind of environment you need to build libdispatch in to get a successful compile. The brief "open xcode and hit build" attempt that I made this morning was not so much a success. Matt -- Matt Wright matt(a)sysctl.co.uk http://www.sysctl.co.uk

4 8

Re: [libdispatch-dev] I missed the intro message ;)
by Matt Wright 12 Sep '09

12 Sep '09

On 12 Sep 2009, at 13:01, Robert Watson wrote: > So on FreeBSD, I've simply tagged libdispatch_init() as > __attribute__ ((constructor)). This may well work on Leopard. You learn something new everyday. Just tagged my init function with that and all is well. So yes, it works on Leopard too. M

1 0

Re: [libdispatch-dev] I missed the intro message ;)
by Matt Wright 12 Sep '09

12 Sep '09

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

2 1

Welcome to libdispatch-dev!
by Kevin Van Vechten 11 Sep '09

11 Sep '09

Welcome to libdispatch-dev! The libdispatch-dev mailing list is intended to be used for technical discussion related to libdispatch. At least initially, we intend this list to be dual-purpose for both the discussion of libdispatch API usage as well as discussion of the internals of libdispatch. As the project matures it may become necessary to spin off another discussion list to separate these two topics. The libdispatch sources hosted at Mac OS Forge correspond to the implementation provided in Mac OS X version 10.6 Snow Leopard. Projects currently being undertaken with these sources include: * Setting up a Mac OS X build environment. Use of DarwinBuild <http://darwinbuild.macosforge.org/> to allow modified libdispatch sources to be deployed in a custom libSystem on Mac OS X. * Makefile/autoconf based build system. To facilitate porting to other platforms such as FreeBSD or Linux. * OS abstraction / refactoring Investigations around abstracting and refactoring the code base to support other operating systems, particularly in the area of dispatch event sources (current based on kqueues). We look forward to your participation! Kevin Van Vechten On behalf of the GCD team

2 1