- libdispatch-dev - lists.macosforge.org

Block not released after dispatch_source_set_event_handler
by Allan Odgaard 25 Feb '13

25 Feb '13

I am seeing an issue where the block given to dispatch_source_set_event_handler appear not to be released when a new handler is set. If I build and run the code below: xcrun clang++ -std=c++11 -stdlib=libc++ test.cc It outputs the ‘create’ line, but never any ‘destroy’. If I don’t call dispatch_source_set_event_handler then I see the expected ‘destroy’. Alternatively I can call an extra Block_release(), which also results in the shared pointer being destroyed. This is on Mac OS X 10.8.2 Build 12C60 using Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn). ----------8<---------- #include <dispatch/dispatch.h> #include <Block.h> #include <stdio.h> #include <memory> void setup_dispatch_source () { struct record_t { record_t () { fprintf(stderr, "%p: create\n", this); } ~record_t () { fprintf(stderr, "%p: destroy\n", this); } }; std::shared_ptr<record_t> record(new record_t); auto block = Block_copy(^(){ fprintf(stderr, "%p\n", record.get()); }); dispatch_source_t source = dispatch_source_create(DISPATCH_SOURCE_TYPE_VNODE, open("/tmp", O_EVTONLY, 0), DISPATCH_VNODE_REVOKE, dispatch_get_main_queue()); dispatch_source_set_event_handler(source, block); dispatch_source_set_event_handler_f(source, NULL); Block_release(block); } int main (int argc, char const* argv[]) { setup_dispatch_source(); return 0; }

2 3

MountainLion libdispatch sources pushed to macosforge repo
by Daniel A. Steffen 19 Dec '12

19 Dec '12

I've committed the MountainLion libdispatch source drop from opensource.apple.com to trunk of the macosforge repository. The autotools buildsystem & testsuite have also been updated, c.f. INSTALL for the additional dependencies on OS X (not required on other platforms). 'make check' passes all tests on MountainLion, and the library built per INSTALL via the autotools buildsystem can be used to replace the system library. Looking forward to contributions of portability fixes for other platforms! Daniel commit 16c9bb430e971b484fd2c80cbb573aa3644e6fb1 Author: dsteffen(a)apple.com <dsteffen@apple.com@5710d607-3af0-45f8-8f96-4508d4f60227> Date: Thu Aug 9 05:09:03 2012 +0000 MountainLion macosforge testsuite git-svn-id: http://svn.macosforge.org/repository/libdispatch/trunk@215 5710d607-3af0-45f8-8f96-4508d4f60227 25 files changed, 1440 insertions(+), 149 deletions(-) commit 415e764f7de27656c266e3659d1fe428152c646b Author: dsteffen(a)apple.com <dsteffen@apple.com@5710d607-3af0-45f8-8f96-4508d4f60227> Date: Thu Aug 9 05:08:56 2012 +0000 autotools buildsystem and portability changes for MountainLion source git-svn-id: http://svn.macosforge.org/repository/libdispatch/trunk@214 5710d607-3af0-45f8-8f96-4508d4f60227 11 files changed, 112 insertions(+), 34 deletions(-) commit a27eef27f38b7cd2c3ffe628f2b0eb270279db26 Author: dsteffen(a)apple.com <dsteffen@apple.com@5710d607-3af0-45f8-8f96-4508d4f60227> Date: Thu Aug 9 05:08:50 2012 +0000 <rdar://problem/11754320> git-svn-id: http://svn.macosforge.org/repository/libdispatch/trunk@213 5710d607-3af0-45f8-8f96-4508d4f60227 1 file changed, 8 insertions(+), 6 deletions(-) commit 048e34b21a87719866e5c998bfef4b39bee27af9 Author: dsteffen(a)apple.com <dsteffen@apple.com@5710d607-3af0-45f8-8f96-4508d4f60227> Date: Thu Aug 9 05:08:47 2012 +0000 import MountainLion libdispatch-228.18 source drop git-svn-id: http://svn.macosforge.org/repository/libdispatch/trunk@212 5710d607-3af0-45f8-8f96-4508d4f60227 59 files changed, 3922 insertions(+), 1048 deletions(-) commit 256c038abd7e2d6b50f5bb417bb77f4f67d610cd Merge: adf9b1f fd874f5 Author: dsteffen(a)apple.com <dsteffen@apple.com@5710d607-3af0-45f8-8f96-4508d4f60227> Date: Wed Aug 1 21:00:35 2012 +0000 merge Lion branch to trunk git-svn-id: http://svn.macosforge.org/repository/libdispatch/trunk@211 5710d607-3af0-45f8-8f96-4508d4f60227

4 4

OpenGCD
by Mark Heily 07 Nov '12

07 Nov '12

I have created a new project called OpenGCD that is designed to make it easier for people to use libdispatch on non-Apple platforms. It is essentially a combination of libdispatch and the other necessary libraries (libkqueue, libpthread_workqueue, and libBlocksRuntime). Here is the link: https://sourceforge.net/projects/opengcd/ Right now, it builds on Linux and Android. I have uploaded binaries for Android on ARM processors, and intend to release binaries for other platforms soon. These will provide a single libdispatch.so (or dispatch.dll) that is statically linked with the other libraries. This one library will provide all the bits necessary to compile programs that use GCD. Hopefully, this project will serve as an incubator for patches that will eventually wind up in the official libdispatch repository. If you are interested in following this project, please subscribe to the mailing list(s). Cheers, - Mark

1 0

Mountain Lion libdispatch for Linux
by Nick Hutchinson 17 Oct '12

17 Oct '12

Hi all, I've written some portability fixes to get Mountain Lion's libdispatch up and running on Linux, and my fork is up on Github for anyone who's interested: https://github.com/nickhutchinson/libdispatch. I used Mark Heily's patches[1] that were previously posted on this list as a starting point. Note that I've had no previous experience with Autotools, and so the patches might be a little rough around the edges. Feedback is welcome. The test suite builds, and most tests pass. However, the following three tests are failing, and I'd love to know why! - dispatch_starfish - dispatch_io - dispatch_vnode The test output is here: https://gist.github.com/3903724 Cheers, Nick [1] http://lists.macosforge.org/pipermail/libdispatch-dev/2012-August/000676.ht…

2 3

dispatch_suspend() does not affect child queues
by Michael Roitzsch 06 Aug '12

06 Aug '12

Hi libdispatch team, I have a question regarding the indented behavior and use of dispatch multiple queues: If a queue A has its target set to queue B and queue B is suspended with dispatch_suspend(B), why are blocks from queue A still executed? I was expecting dispatch_suspend(X) to silence the entire subsystem of queues directly or indirectly targeting queue X, but it does not. Instead, only the queue X I pass in is suspended, all other queues seem unaffected. I attached an Xcode project (tested on OS X 10.8.0) to demonstrate the issue. I am using two serial queues "low" and "high" to implement the front enqueue pattern to execute emergency work: The "low" queue targets the "high" queue. Blocks are usually enqueued on "low", emergency work is enqueued on "high" so it can bypass all the work queued in "low". This works fine when line 27 is commented out. However, as soon as I give a different subsystem of my code (imagine this being a third party library) access to the "low" queue, this subsystem can create a hidden private queue that feeds into "low". The emergency block will now experience undue delay, because suspending the "low" queue does not suspend the private queue. I would like to understand the rationale for this behavior of libdispatch. Michael

2 2

Merging Lion branch to trunk
by Daniel A. Steffen 31 Jul '12

31 Jul '12

I'm preparing for the opensource release of the MountainLion libdispatch to the macosforge repository. As part of that effort I'm planning to merge the Lion branch http://svn.macosforge.org/repository/libdispatch/branches/Lion to trunk (replacing the trunk with the branch). The current trunk (SnowLeopard-era) version of libdispatch is quite old at this point, all new development has been happening on the Lion branch for multiple years, but it is possible that not all contributed portability changes have made it there. I'm hoping that this merge will clarify the state of ongoing development in the repository, and hopefully prompt contribution of portability fixes for the upcoming MountainLion changes. Daniel

3 3

dispatch_once_t must have global or static scope?
by Michael Ash 26 Jul '12

26 Jul '12

The GCD reference on developer.apple.com says, regarding dispatch_once_t: "Variables of this type must have global or static scope. The result of using this type with automatic or dynamic allocation is undefined." https://developer.apple.com/library/mac/#documentation/Performance/Referenc… However, I can't find any explanation of why that would be the case, either in the documentation or the libdispatch code. Does anyone have any insight to shed on this? It's occasionally useful to have a dispatch_once_t member variable in an Objective-C object, and it would be nice to know if that's actually OK or not. I have a hard time figuring out how GCD could possibly care about the storage scope of the variable, but it's possible that I'm overlooking something. Mike

2 4

Memory issues with libdispatch
by Aldrin Martoq Ahumada 30 Apr '12

30 Apr '12

Hi, I have been testing sample code from the wiki and found that libdispatch is alloc'ing a lot of memory without releasing it, both in OS X (Lion 10.7.3, Xcode 4.3.2) and Linux (manually compiled and installed). The code creates a SIGHUP signal source, with a handler that calls 100_000 writes to a logfile. The write to a log is queued in a serial queue. The first run shows normal memory usage (8-9 MiB both Linux and OS X). After sending a "kill -1 <pid>" memory usage increases 1-20MiB every time I send the SIGHUP signal. I have tried compiling with -fobj-arc and without it, but the result is the same. I removed the NSString usage in the br_log function, but the leak is not there: it is somewhere inside libdispatch. I tried both valgrind and Xcode Instruments, but no leaks are found. Thanks in advance, ---- ini ---- // // main.m // test02 // // Created by Aldrin Martoq on 4/29/12. // Copyright (c) 2012 __MyCompanyName__. All rights reserved. // #include <unistd.h> #import <Foundation/Foundation.h> #import <dispatch/dispatch.h> static FILE *log_file = NULL; static NSString *log_filename = @"/tmp/br.log"; static dispatch_queue_t log_queue; void br_log(NSString *format, ...) { @autoreleasepool { va_list ap; va_start(ap, format); NSString *s = [[NSString alloc] initWithFormat:format arguments:ap]; va_end(ap); if (log_file == NULL) { log_queue = dispatch_queue_create("cl.martoq.log_queue", NULL); log_file = fopen([log_filename cStringUsingEncoding:NSUTF8StringEncoding], "a"); NSLog(@"Log file created: %@", log_filename); } dispatch_async(log_queue, ^{ @autoreleasepool { const char *c = [s cStringUsingEncoding:NSUTF8StringEncoding]; fputs(c, log_file); fputs("\n", log_file); fflush(log_file); [s release]; } }); } } void br_setup() { signal(SIGHUP, SIG_IGN); dispatch_source_t sig_src = dispatch_source_create(DISPATCH_SOURCE_TYPE_SIGNAL, SIGHUP, 0, dispatch_get_main_queue()); dispatch_source_set_event_handler(sig_src, ^{ dispatch_async(dispatch_get_main_queue(), ^{ printf("Caught SIGHUP\n"); for (int i = 0; i < 100000; i++) { br_log(@"prueba: %d", i); } }); }); dispatch_resume(sig_src); } int main(int argc, const char * argv[]) { @autoreleasepool { // insert code here... NSLog(@"Hello, World!"); br_setup(); dispatch_main(); } return 0; } ---- fini ---- Aldrin Martoq A. http://aldrin.martoq.cl/

2 4

Question on race condition when using dispatch_group_notify_f
by Christopher Jones 02 Apr '12

02 Apr '12

To whom it may concern, I have found a race condition using the port of libdispatch from http://mark.heily.com/sites/mark.heily.com/files/libdispatch-f16-SRPMS.tgz. The race condition manifests when doing the equivalent of void run(void* iContext) { dispatch_group_t g = reinterpret_cast<dispatch_group_t>(iContext); dispatch_group_async_f(g, dispatch_get_global_queue(0, 0), g, do_work); dispatch_group_notify_f(g, dispatch_get_global_queue(0, 0), g, run); } The idea is to have a new 'run' task start up after the previous 'do_work' task has finished. However, with a system under heavy load I see that 'run' can be called before its instance of 'do_work' has finished. This happens because of a race condition in '_dispatch_group_wake' _dispatch_group_wake(dispatch_semaphore_t dsema) { struct dispatch_sema_notify_s *tmp; struct dispatch_sema_notify_s *head = (struct dispatch_sema_notify_s *)dispatch_atomic_xchg(&dsema->dsema_notify_head, NULL); ... while (head) { dispatch_async_f(head->dsn_queue, head->dsn_ctxt, head->dsn_func); _dispatch_release(head->dsn_queue); do { tmp = head->dsn_next; } while (!tmp && !dispatch_atomic_cmpxchg(&dsema->dsema_notify_tail, head, NULL)); free(head); head = tmp; } … } Under heavy load, the thread processing _dispatch_group_wake can be swapped out right after the first call to 'dispatch_async_f'. The task can then call 'run(void* iContext)' which can make it all the way to the end of that function thereby adding a new task to the tail of the dispatch_group. Once the '_dispatch_group_wake' thread reawakens, it now has a new entry in 'head->dsn_next' (since in dispatch_group_notify_f the 'head' and 'tail' refer to the same memory address for this problem). This new entry is processed which causes the 'run' to go off before the associated 'do_work' finishes. You can find a small test which can, usually, exhibit the error and cause an assert to fail http://dl.dropbox.com/u/11356841/raceCondition.cpp This test has succeeded in exhibiting the error for me when run on a 16 core (4CPUs with each CPU having 4 cores) machine under Scientific Linux 6 [which is derived from Red Hat Enterprise 6]. So my question is, is the idea of having dispatch_group_notify_f effectively call itself not a supported activity or is this a bug that should be fixed? Sincerely, Chris Dr Christopher Jones Fermi National Accelerator Laboratory cdj(a)fnal.gov

2 1

[PATCH] Support for the GNUstep Objective-C/Blocks runtime
by Niels Grewe 20 Mar '12

20 Mar '12

Hi all, the GNUstep project maintains an Objective-C runtime library [0] that also features support for blocks. Until very recently, we were exposing quite a bit less about the block data structures than the blocks runtime from compiler-rt, but I just got around to adding them to a public header. Now it works like a charm with libdispatch and I was hoping that you might be willing to include the attached patch, which enables the configure script to detect the presence of a blocks-enabled Objective-C runtime. Best regards, Niels [0] http://svn.gna.org/svn/gnustep/libs/libobjc2/trunk/

2 4