headers
Adam Ernst | 19 Apr 2013 22:48

Replacement for dispatch_get_current_queue

The design of dispatch_get_current_queue is clearly problematic, as its docs indicate. I've heard
rumors the function will be deprecated and removed soon.

We currently use it for queue affinity asserts (for which it serves ably). Is there any plan on what it might
be replaced with for this purpose?

Adam
Permalink | Reply | 3 comments |
headers
Frank Rehwinkel | 15 Mar 2013 21:18
Picon

Build and compile with libdispatch and -fobjc-arc on Linux

Am looking for confirmation of what should be working and what build flags to use to make this work.

On a Debian-based Linux system, Ubuntu 64-bit 12.04 or 12.10, using trunk from libobjc2, for Objective-C code to use Clang's -fobjc-arc that also wants to link with the libdispatch library, 
what is the recommended set of flags for building libdispatch and for building the code itself?  

What I've tried so far hasn't worked but rather than clutter this first post with all my attempts and the compiler error and later the execution
failure, I thought it worth checking that I am starting with the proper base.  I have found nothing online about using libdispatch with automatic reference counting on Linux.  Both are
such powerful tools I was surprised not to find this all spelled out already so I wonder if it just works for others or if no one else has tried.

For the build of libdispatch, I followed this recipe:

    cd libdispatch-src
    sh autogen.sh
    ./configure CFLAGS="-I/usr/include/kqueue" LDFLAGS="-lkqueue -lpthread_workqueue -pthread -lm" 
    make
    sudo -E make install
    sudo ldconfig

And to build the Objective-C source with GNUstep's libobjc2 runtime library, I used these flags.

    clang testfile.m `gnustep-config --objc-flags` `gnustep-config --objc-libs` -fobjc-runtime=gnustep-1.7 -fblocks  -lobjc -ldispatch -lgnustep-base

I'm using the svn trunk for libobjc2 as that has a recent bug fix for blocks and ARC.  I pulled the libdispatch src from git://github.com/nickhutchinson/libdispatch.git.

If noone has any suggestion for a different build approach, I will attach the compile error I ran into and then the runtime error that is left to figure out.

Thank you,
-Frank
_______________________________________________
libdispatch-dev mailing list
libdispatch-dev@...
https://lists.macosforge.org/mailman/listinfo/libdispatch-dev
Permalink | Reply | 0 comments |
headers
Allan Odgaard | 23 Feb 2013 17:04

Block not released after dispatch_source_set_event_handler

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;
}
Permalink | Reply | 3 comments |
headers
Mark Heily | 7 Nov 2012 01:12

OpenGCD

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
_______________________________________________
libdispatch-dev mailing list
libdispatch-dev@...
http://lists.macosforge.org/mailman/listinfo/libdispatch-dev
Permalink | Reply | 0 comments |
headers
Nick Hutchinson | 17 Oct 2012 07:56
Picon

Mountain Lion libdispatch for Linux

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.html
Permalink | Reply | 3 comments |
headers
Daniel A. Steffen | 9 Aug 2012 07:23
Picon
Favicon

MountainLion libdispatch sources pushed to macosforge repo

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@... <dsteffen@... <at> 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 <at> 215 5710d607-3af0-45f8-8f96-4508d4f60227

 25 files changed, 1440 insertions(+), 149 deletions(-)

commit 415e764f7de27656c266e3659d1fe428152c646b
Author: dsteffen@... <dsteffen@... <at> 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 <at> 214 5710d607-3af0-45f8-8f96-4508d4f60227

 11 files changed, 112 insertions(+), 34 deletions(-)

commit a27eef27f38b7cd2c3ffe628f2b0eb270279db26
Author: dsteffen@... <dsteffen@... <at> 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 <at> 213 5710d607-3af0-45f8-8f96-4508d4f60227

 1 file changed, 8 insertions(+), 6 deletions(-)

commit 048e34b21a87719866e5c998bfef4b39bee27af9
Author: dsteffen@... <dsteffen@... <at> 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 <at> 212 5710d607-3af0-45f8-8f96-4508d4f60227

 59 files changed, 3922 insertions(+), 1048 deletions(-)

commit 256c038abd7e2d6b50f5bb417bb77f4f67d610cd
Merge: adf9b1f fd874f5
Author: dsteffen@... <dsteffen@... <at> 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 <at> 211 5710d607-3af0-45f8-8f96-4508d4f60227
Permalink | Reply | 4 comments |
headers
Michael Roitzsch | 5 Aug 2012 19:06
Picon
Favicon

dispatch_suspend() does not affect child queues

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
Attachment (GCD-Test.zip): application/zip, 2619 bytes
_______________________________________________
libdispatch-dev mailing list
libdispatch-dev@...
http://lists.macosforge.org/mailman/listinfo/libdispatch-dev
Permalink | Reply | 2 comments |
headers
Daniel A. Steffen | 30 Jul 2012 22:59
Picon
Favicon

Merging Lion branch to trunk

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
Permalink | Reply | 3 comments |
headers
Michael Ash | 26 Jul 2012 19:14
Picon

dispatch_once_t must have global or static scope?

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."


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
_______________________________________________
libdispatch-dev mailing list
libdispatch-dev@...
http://lists.macosforge.org/mailman/listinfo/libdispatch-dev
Permalink | Reply | 4 comments |
headers
Aldrin Martoq Ahumada | 30 Apr 2012 08:09
Picon
Gravatar

Memory issues with libdispatch

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 = <at> "/tmp/br.log";
static dispatch_queue_t log_queue;


void br_log(NSString *format, ...) {
    <at> 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( <at> "Log file created: % <at> ", log_filename);
        }
        
        dispatch_async(log_queue, ^{
            <at> 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( <at> "prueba: %d", i);
            }
        });
    });
    dispatch_resume(sig_src);
}


int main(int argc, const char * argv[]) {
    <at> autoreleasepool {
        // insert code here...
        NSLog( <at> "Hello, World!");
        br_setup();
        dispatch_main();
    }
    return 0;
}
---- fini ----



Aldrin Martoq A.

_______________________________________________
libdispatch-dev mailing list
libdispatch-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/libdispatch-dev
Permalink | Reply | 4 comments |
headers
Christopher Jones | 2 Apr 2012 23:28
Favicon

Question on race condition when using dispatch_group_notify_f

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@...
Permalink | Reply | 1 comment |

Gmane