- libdispatch-dev - lists.macosforge.org

dispatch source for multi-client sockets
by Mikkel Fahnøe Jørgensen 22 Sep '09

22 Sep '09

How does one create a dispatch source that responds to multiple connections on the same socket, that is, listening on a socket with a backlog larger than 1? In the online doc it seems that you should have a connected socket to read from, the same way as reading from a file. But documentation also says you need a socket returned from listen(). So where does the accept() call fit into this? Specifically it would be nice to avoid blocking on accept() before creating a read source. I found this echo server example based on kqueue events which seems to receive a read event. First the handler will accept the socket, then do normal read processing. Is this also how it should work with libdispatch, and if so, what about other platforms. http://www.monkeys.com/freeware/kqueue-echo.c And how about similar event sources for DNS lookup? Libevent did a bit of work on these issues, and I see it has already been mentioned on this mailing list. Related: I don't see any examples of custom event sources - but I thought that might also be a way to schedule client handlers? Finally, what is the policy on busy loops and locking operations? One could for example push a blocking socket accept() call onto a queue, but this consumes a thread from a thread pool that is designed to reflect number of cpus not number of long running tasks. Alternatively one could create a dedicated thread for this purpose, but that doesn't seem very elegant. Regards, Mikkel

3 2

Compiling OpenMP directives as calls to libdispatch API?
by Stéphane Letz 17 Sep '09

17 Sep '09

Hi, Would it be technically feasible to compile OpenMP directives as calls to libdispatch API? This would possibly allow OpenMP based code to be easily ported on GCD. Comments? Stephane Letz

1 0

libdispatch port to FreeBSD (was: [libdispatch-changes] [27] trunk/src)
by Robert Watson 15 Sep '09

15 Sep '09

Dear all-- I have committed an initial autoconf/automake/libtool build framework to libdispatch svn, and a first cut at conditionally compiling Apple-specific pieces of libdispatch. This allows libdispatch to build on both FreeBSD and Mac OS X Snow Leopard. Some notes for FreeBSD hackers: - Several kqueue extensions (EVFILT_USER, NOTE_TRIGGER, EV_RECEIPT, and EV_DISPATCH) are required in the FreeBSD kernel, and hopefully will go into the FreeBSD tree in the next couple of days. - Blocks are definitely not yet supported -- there seems to be a lot of interest, so I'm optimistic. As compilers aren't my forte, any assistance in this department would be most appreciated. :-) - On FreeBSD, there is no support for Apple's pthread work queue primitive, so I'm using the fallback worker code in libdispatch. The FreeBSD kernel community needs to have a conversation about the right way to address this requirement, but in the mean time the worker model should be fine. - There are also some kqueue events present in FreeBSD but not in Mac OS X; these may require tweaks to libdispatch to fully support by GCD-aware applications using these FreeBSD events. - I have developed and tested on a 32-bit Intel system; the comments below on -march on Mac OS X likely apply for FreeBSD/amd64 users as well. Some notes for Mac OS X hackers: - For now, you will need to hand-trim the -march line from src/Makefile. This should be fixed soon by some further autoconf work. - When I use the externally-built dylib on Snow Leopard, test programs spin. This may be due to interference between the libSystem dispatch code and the dylib -- possibly forcing the use of pthread_create_key rather than reserved keys would help. - I have not attempted to configure/build for Leopard as yet, but this change should make that a lot easier. EVFILT_USER is likely the biggest obstacle. Some notes for Linux hackers: - The lack of kqueue support is the critical obstacle in a port to Linux. It may be that a kqueue emulation library based on epoll (or even libevent) could fill this gap. If someone wants to look at this, pay very careful attention to kqueue semantics, as libdispatch relies on them heavily. Please consider this a work-in-progress -- don't be surprised when it doesn't build, let alone work. :-) Finally: this work would not have been possible without the support of Jordan Hubbard, Kevin Van Vechten, Dave Zarzycki, Bill Siegrist, and Apple. I am surprised by how easily the porting has gone so far -- it's a credit to their careful planning and quality of implementation that it has gone so smoothly. Thanks also to Peter O'Gorman and Colin Percival for their assistance with auto*, my nemesis. With any luck, there will be more good porting news to report in the near future! Thanks, Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Mon, 14 Sep 2009 11:46:19 -0700 (PDT) From: source_changes(a)macosforge.org Reply-To: libdispatch-dev(a)lists.macosforge.org To: libdispatch-changes(a)lists.macosforge.org Subject: [libdispatch-changes] [27] trunk/src Revision 27 Author robert(a)fledge.watson.org Date 2009-09-14 11:46:18 -0700 (Mon, 14 Sep 2009) Log Message Port of libdispatch to the FreeBSD operating system, which consisted of disabling various Mac OS X-specific portions of the library (such as Mach), providing portable versions of certain services internally (POSIX semaphores instead of Mach semaphores, clock_gettime() instead of mac_absolute_time()), and providing an autoconf/automake/libtool build infrastructure. This is just a first cut, refinement to follow. Conditionalize portions of the libdispatch build as follows: HAVE_MACH If Mach is present, support Mach ports throughout libdispatch. USE_LIBDISPATCH_INIT_CONSTRUCTOR If defined, add the 'constructor' attribute to libdispatch_init so that it runs as part of library initialization. This is not needed in Mac OS X libSystem due to explicit invocation of libpthread_init by libsyscall, but is for a stand-alone library. HAVE_DECL_EVFILT_SESSION, HAVE_DECL_NOTE_SIGNAL, HAVE_DECL_NOTE_REAP, HAVE_DECL_NOTE_NONE, HAVE_DECL_VQ_UPDATE, HAVE_DECL_VQ_VERYLOWDISK Conditionally support kqueue events that are not present on FreeBSD. DISPATCH_NO_LEGACY Expand the scope of this existing macro to allow libdispatch to build without legacy.c. HAVE_MACH_ABSOLUTE_TIME Wrap mach_absolute_time() in _dispatch_absolute_time(), and provide a portable clock_gettime() implementation. Some further refinment will be required here. USE_APPLE_SEMAPHORE_OPTIMIZATIONS Only use non-portable assembly optimizations of dispatch semaphores if supported. HAVE_SEM_INIT Use POSIX semaphores if Mach semaphores aren't present; further ifdef'ing possibly required here. If neither HAVE_MACH nor HAVE_SEM_INIT are present, the compile will fail. USE_APPLE_CRASHREPORTER_INFO Only define Mac OS X crashreporter state if requested. HAVE_PTHREAD_WORKQUEUES Only compile in support for pthread work queues if present; otherwise force use of normal worker threads. HAVE_PTHREAD_KEY_INIT_NP If defined, use non-portable allocation of pthread keys--otherwise, use pthread_create_key(). USE_APPLE_TSD_OPTIMIZATIONS Only use non-portable assembly optimizations if dispatch thread- specific data if this is defined. HAVE_MALLOC_CREATE_ZONE If not present, use compat/malloc_zone.h which implements the malloc zone APIs using normal malloc(3). Also fix some portability nits for building, such as casting before using long as a format string for several types. Note that this port will not build or run on a stock FreeBSD release or svn distribution yet, as it relies on kqueue extensions not committed back to FreeBSD yet. There are several known issues, such as how best to map CLOCK_UPTIME or CLOCK_MONOTONIC struct timespec timestamps into a Mach absolute time int64_t number space. Also, the POSIX semaphore ifdefing is adequate but not complete. Modified Paths * trunk/src/benchmark.c * trunk/src/dispatch.h * trunk/src/internal.h * trunk/src/legacy.h * trunk/src/os_shims.h * trunk/src/private.h * trunk/src/queue.c * trunk/src/queue_internal.h * trunk/src/semaphore.c * trunk/src/semaphore_internal.h * trunk/src/shims.c * trunk/src/source.c * trunk/src/source.h * trunk/src/source_private.h * trunk/src/time.c Diff Modified: trunk/src/benchmark.c (26 => 27)

8 9

Does GCD has a "global view" of all running processes?
by Stéphane Letz 15 Sep '09

15 Sep '09

Hi, After reading several things on GCD on the net, it is not yet clear if GCD is mainly a "per process" library, or is supposed to have a "global view" of all processes, so that to allocate "not too much" threads in each process, and avoid having a number of threads that finally exceed the number of available cores on the machine. What is the situation? Thanks Stephane Letz

4 4

Using libdispatch in a real-time context
by Stéphane Letz 15 Sep '09

15 Sep '09

Hi, Audio developers on OSX would be interested to be able to use libdispatch in their applications. We understand that right now libdispatch is not designed to be used in a RT context (I guess because of memory issues when using blocks...). Would it be technically possible to extend libdispatch to be used in a RT context? so basically having worker threads to be setup with "time- constraint" kind of priority on OSX... and possibly working on a RT capable memory manager for blocks management ? Thanks Stéphane Letz

2 1

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