- libdispatch-dev - lists.macosforge.org

Canceling/releasing a suspended timer
by Kevin Wojniak 15 Dec '10

15 Dec '10

It appears that releasing a suspended timer is not allowed and will crash. Also, canceling the suspended timer does not appear to work and call the cancel handler. Are these correct assumptions? If so, then if I have a suspended timer, is the proper way to cancel or release it is to first resume? However I would imagine there is still the off chance that the timer could fire in between those calls to resume and cancel, requiring a flag to be set. Kevin

2 2

Some questions about source handling
by cee1 11 Dec '10

11 Dec '10

Hi all, Questions: 1. How does a source's event handler accesses data returned by kevent? Data returned by kevent will finally be recorded is ds_data field in _dispatch_source_latch_and_call. The event handler will be called with ds_handler_ctxt, which shoule be do_ctxt. "do_ctxt" can be set by function dispatch_set_context. The problem is: - If a handler need to access ds_data, we have to set a proper do_ctxt (e.g. a do_ctxt of source). That's not convenient. - "ds_data" is a member of dispatch_source_t, and dispatch_source_t is an opaque struct to client code. 2. We have custom source of type DISPATCH_SOURCE_TYPE_DATA_ADD and DISPATCH_SOURCE_TYPE_DATA_OR, and can use dispatch_source_merge_data to fire custom sources. Why we don't have an 'is_level' source? An "is_level" source may not make much sense, but can be attached with cancel handler, this may be useful in some cases. -- Regards, - cee1

3 4

libdispatch threads, blocked SIGINT and child process
by Thomas Clement 03 Dec '10

03 Dec '10

Hello, I have encountered a strange behavior when using libdispatch (OS X 10.6.5). I'm not sure if there is a bug in libdispatch or else what the correct fix is for me. I found myself in the situation of doing a fork/exec/waitpid from a libdispatch thread, the child process waiting for user input, then doing ctrl-c in my Terminal window. I would expect the child process to also be terminated, however the child process is still running, consuming lots of cpu (and its ppid is now 1 which is weird). I have noticed that libdispatch calls pthread_sigmask() when creating new threads blocking many signals. I have found that calling pthread_sigmask() in my dispatch_asynced code to unblock the SIGINT signal fixes the issue (the child process is also terminated when doing a ctrl-c in my Terminal window). You can reproduce the issue using the attached sample code (which uses launchctl as the child process but it could be anything else). You can run the process from the Terminal window (./sigdispatch_br) then doing ctrl-c and watching the child process from a "top". So, what do you guys think? Thanks, Thomas

2 2

[PATCH] various portability issues
by Mark Heily 10 Nov '10

10 Nov '10

I have attached a collection of patches that allows libdispatch to build on Linux and Solaris. Many thanks to Joakim Johansson for providing the Solaris patches and testing everything. The commands I used to build on Linux are: CC="clang" LD="llvm-ld-2.8" CFLAGS="-I/usr/local" \ LDFLAGS="-L/usr/local" LIBS="-lbsd" ./configure && make The commands Joakim used to build on Solaris are: ./configure CFLAGS="-m64 -I/usr/local/include" \ LDFLAGS="-L/usr/local/lib” gmake Please review these and consider them for inclusion in the trunk. Regards, - Mark

1 0

BUG in libdispatch: 10F569 - 1730 - 0x11
by Ruben Laguna 04 Nov '10

04 Nov '10

Hi, My system (MacBook Pro) is crashing/freezing regularly 20 seconds after a wake up and the last message in the Console.app before the crash is a SystemUIServer[184] BUG in libdispatch: 10F569 - 1730 - 0x11 I downloaded the git repo to find out what this means and if it is really related to my system freeze. according to queue.c the format of this log is _dispatch_log("BUG in libdispatch: %s - %lu - 0x%lx", _dispatch_build, (unsigned long)line, val); So build 10F569, line 1730 (which file?), value 0x11. Anyone can tell me exactly what this error log means , how to workaround it or point me to the right forum to ask? Thanks /Rubén -- /Rubén

4 4

Patch submissions for Solaris compatibility
by Joakim Johansson 04 Nov '10

04 Nov '10

I submitted a few patches back in July for Solaris portability (enough to get libdispatch through most of the test suite when built with gcc together with libkqueue/libpthread_workqueue) - was there any (stylistic or other) issues with those that I should address for them being considered, or ...? Cheers, Joakim

1 0

What's cooking for libdispatch in future?
by Danilo Egea 24 Oct '10

24 Oct '10

Some new feature is being developed for libdispatch in the near future? I don't see movement in subversion. For OSX Lion we will have something new? Thanks! sorry my english translated with help google :'( __________________________________________________ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/

1 0

Windows Port
by Brent Fulgham 23 Oct '10

23 Oct '10

I've noticed that the WebKit builds on Windows have started making use of libdispatch. Do you think we might get access to these changes in the libdispatch project? I'd sure love to take advantage of them! Thanks, -Brent

3 2

global queue or many serial queues?
by Greg Pfeil 21 Oct '10

21 Oct '10

I'm converting some code to use libdispatch instead of my home-grown event queue, and I'm wondering what the best approach is. There is a tree, and each task in the queue operates on a node and potentially its parent and children. Before I converted my code to libdispatch, I had a single concurrent queue and each node in the tree had a mutex. When a node was operated on, it would lock its parent, itself, and its children in that order (this isn't optimal for the application, but it was a conservative approach that meant I didn't have to think about deadlocks). Obviously this can be translated pretty directly to libdispatch, using a global concurrent queue and semaphores. However, I was wondering if (even with all the semaphores) it might be beneficial to create a serial queue for each node. In my mental model, this would eliminate blocking on threads each trying to operate on the same node – the semaphores would really only cause blocking when two adjacent nodes are being operated on. Or is it the case that a single concurrent queue would work just as well – once a task is blocked, it just grabs another one and starts that. And, if I'm using multiple serial queues, is it also beneficial to suspend the queues for the parent and children nodes while the semaphores are locked? I know the answers depend on other questions like "how long does a task take to run?" (pretty short, fraction of a second), "how many queues will you have?" (can vary a lot, but "dozens" seems reasonable), "is the tree tall or wide?" (probably more wide), and probably plenty of other things. So, hopefully this will at least help me to understand the tradeoffs involved. Thanks.

2 1

Queue size
by Thomas Clement 07 Oct '10

07 Oct '10

> Queues cannot have variable widths - it's either 1 or "infinite". That idea was considered but ultimately dropped given that it only made submitting things to queues even less deterministic in terms of where/how they would run, and there is already a way (again, semaphores) to get that behavior, so this would have only added complexity to all queues for little overall gain. I'm confused. What about the dispatch_queue_set_width() private function? Isn't this already implemented and functional? Thomas

3 6