gmane.comp.macosx.libdispatch.devel

Re: Replacement for dispatch_get_current_queue

Daniel A. Steffen — 2013-04-20T02:50:27

Allan,

the dispatch_retain() here is not safe and can crash with a resurrection assertion if the queue in question has already been released by its owner.

as the documentation says, you must not modify the queue returned by dispatch_get_current_queue() in any way, including retaining/releasing it or submitting blocks to it.

If you need something like this, you must track & memory manage the queues of interest yourself, e.g. by passing them as parameters, or setting them as queue-specific context etc.

Daniel

On Apr 19, 2013, at 19:33, Allan Odgaard <lists+libdispatch-4x29EjoDHl1BDgjK7y7TUQ< at >public.gmane.org> wrote:

Re: Replacement for dispatch_get_current_queue

Allan Odgaard — 2013-04-20T02:33:07


I have another use-case where objects can only be accessed from a single thread.

For example:

  class MyClass
  {
    void set_foo (Foo* foo);
    …
  };

  std::shared_ptr<MyClass> create_object ()
  {
    dispatch_queue_t original_queue = dispatch_get_current_queue();
    dispatch_retain(original_queue);

    std::shared_ptr<MyClass> res(new MyClass);

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
      Foo* foo = new Foo; // could be expensive
      dispatch_async(original_queue, ^{
        res->set_foo(foo);
        dispatch_release(original_queue);
      });
    });

    return res;
  }

One solution is to pass the current queue to create_object(), which normally would be the main queue, however, when running tests, it’s the testing framework that decides which queue a test executes in, so tests would have to create their own “inner” queue and run the actual code in that, so that they have a valid queue to pass to create_object().

Another solution woul

Re: Replacement for dispatch_get_current_queue

Thomas Clement — 2013-04-19T21:13:37

On 19 avr. 2013, at 22:48, Adam Ernst <adamjernst-b10kYP2dOMg< at >public.gmane.org> wrote:


Take a look at dispatch_queue_get_specific and dispatch_queue_set_specific.

Thomas

Replacement for dispatch_get_current_queue

Adam Ernst — 2013-04-19T20:48:14

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

Build and compile with libdispatch and -fobjc-arcon Linux

Frank Rehwinkel — 2013-03-15T20:18:53

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="-lkqu

Re: Block not released after dispatch_source_set_event_handler

Daniel A. Steffen — 2013-02-25T08:23:12

not sure, sorry, probably best to ask on objc-language-KAbXV2sdvEinzT0iUeSTvQ< at >public.gmane.org about that one, and specify the exact linker line used (along with the os & tools versions).

Daniel

On Feb 25, 2013, at 0:13, Allan Odgaard <lists+libdispatch-4x29EjoDHl1BDgjK7y7TUQ< at >public.gmane.org> wrote:

Re: Block not released afterdispatch_source_set_event_handler

Allan Odgaard — 2013-02-25T08:13:58

Hi Daniel.

Thanks for the reply — as I was seeing the leak in code that did use the event handler, I spent some more time investigating, and it seems my issue is with linking C++ object files with -fobjc-link-runtime and setting -mmacosx-version-min=10.7.

I am not sure if this is a bug or I am violating some contract by linking with the obj-c run-time for non-obj-c code. Presumably it has to do with the 10.7 ARC-lite compatibility code that clang adds (though my code was pure C++ so did not use ARC).

Kind regards Allan


On Feb 25, 2013, at 6:28 AM, "Daniel A. Steffen" <dsteffen-2kanFRK1NckAvxtiuMwx3w< at >public.gmane.org> wrote:

>

Re: Block not released after dispatch_source_set_event_handler

Daniel A. Steffen — 2013-02-25T05:28:06

Hi Allan,

dispatch sources are created in a suspended state and must be resumed after configuration, see the dispatch_source_create(3) manpage and the SUSPENSION section of dispatch_object(3) for details.

All setters of source configuration are asynchronous in nature and only take effect when the source is not suspended.
Once dispatch_resume(source) is called, the handler block retained by dispatch_source_set_event_handler() will be released when the subsequent dispatch_source_set_event_handler_f() takes effect.

Daniel 

On Feb 23, 2013, at 8:04, Allan Odgaard <lists+libdispatch-4x29EjoDHl1BDgjK7y7TUQ< at >public.gmane.org> wrote:

Block not released afterdispatch_source_set_event_handler

Allan Odgaard — 2013-02-23T16:04:12

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()); });

Re: MountainLion libdispatch sources pushed to macosforge repo

Daniel A. Steffen — 2012-12-19T19:17:57

thanks!

On Aug 8, 2012, at 22:23, Daniel A. Steffen <dsteffen-2kanFRK1NckAvxtiuMwx3w< at >public.gmane.org> wrote:

OpenGCD

Mark Heily — 2012-11-07T00:12:17

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

Re: Mountain Lion libdispatch for Linux

Daniel A. Steffen — 2012-10-17T23:28:53

On Oct 17, 2012, at 16:06, Nick Hutchinson <nshutchinson-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


there is actually no guarantee that the channel cleanup handler must run after all I/O handlers have returned, just that it runs after all the I/O has completed and the file descriptor is safe to close (I/O handlers execute asynchronously to this).


this may well be a bug in the test, I does not reproduce for me on Mac OS X when I add empty files to /usr/lib however. It would be interesting to investigate this further.

Re: Mountain Lion libdispatch for Linux

Nick Hutchinson — 2012-10-17T23:06:14

Hi Daniel,

Thanks for your repsonse. I've been poking around, and I think the dispatch_io test failures might point to a bug in libdispatch proper.

I don't understand most of the logic in io.c, but it seems that in certain cases, a Dispatch I/O channel's cleanup handler can execute concurrently with an I/O handler, instead of waiting until all I/O handler blocks have returned.

I was experiencing this because there were a number of zero-length files in my /usr/lib folder, so the unit test was calling dispatch_io_read() with a `size` parameter of zero. Looking at the io.c code, I see that a request for a read or write of length zero is special-cased in _dispatch_operation_create(), and the I/O handler is enqueued immediately.

Maybe this is the source of the failures? If I update the dispatch_io.c test to call dispatch_io_read() with SIZE_MAX for the `size` parameter, the failures go away.

Regards,
Nick

On 17/10/2012, at 8:03 PM, Daniel A. Steffen wrote:

Re: Mountain Lion libdispatch for Linux

Daniel A. Steffen — 2012-10-17T07:03:11

Hi Nick,

awesome, thanks for the patches!

looking at the test failures:

the dispatch_vnode failure means not all vnode notifications were seen that should have been generated in response to the file rename()s perfomed, this is likely fixable by adjusting the dispatch_semaphore_wait timeout in the test, but could also indicate a problem in the kevent library or somewhere below

dispatch_starfish is essentially a stress test for multithreaded malloc, looks like the latency allowed by the test was exceeded in one case, this does not indicate a serious problem (the timing constants in the test would need to be adjusted for Linux for this to pass).

the dispatch_io failures look more serious and likely indicate a problem with the port of io.c, the asynchronous IO does not seem to be performed correctly, but I can't tell anything more specific about the cause from the output, so you'll probably need to do some debugging...

Daniel


On Oct 16, 2012, at 22:56, Nick Hutchinson <nshutchinson-Re5JQEeQqe8AvxtiuMwx3w

Mountain Lion libdispatch for Linux

Nick Hutchinson — 2012-10-17T05:56:08

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

Re: MountainLion libdispatch sources pushedtomacosforge repo

DrPizza — 2012-09-07T01:46:40

I have asked this before in the past.

iTunes on Windows installs and uses libdispatch. libdispatch.dll appear to be built with VC++. This means that somewhere within Apple there is a version of libdispatch that is buildable on Windows. The version used by the current iTunes (10.6.3) appears to be approximately synced with Lion; it includes the dispatch barrier functions introduced in Lion, but not the new I/O features in Mountain Lion.

Can this source of this be made available?

Re: MountainLion libdispatch sources pushed to macosforge repo

Rui Paulo — 2012-08-10T17:57:12



To avoid any duplicate efforts, I would like to point out that I'm working on a FreeBSD port. I looked at Mark's patch and it seems that we wrote similar portability fixes.

--
Rui Paulo

Re: MountainLion libdispatch sources pushed to macosforge repo

Mark Heily — 2012-08-10T02:00:32

I've attached a patch which addresses most of the build problems on Linux. The
only thing left to do is implement the functionality found in
<libkern/OSByteOrder.h> as needed by src/transform.c. When I manually disabled
the building of transform.c, I was able to compile libdispatch.so on a 64-bit
Debian Linux system.

The patch includes a copy of <sys/queue.h> and strlcpy() copied from the
FreeBSD 9 source tree.

This patch does not include any portability fixes for the testsuite; I will
work on this later and submit a separate patch for it.

Thanks,

 - Mark


_______________________________________________
libdispatch-dev mailing list
libdispatch-dev-qhrM8SXbD5KlRa4neek8BWD2FQJk+8+b< at >public.gmane.org
http://lists.macosforge.org/mailman/listinfo/libdispatch-dev

MountainLion libdispatch sources pushed tomacosforge repo

Daniel A. Steffen — 2012-08-09T05:23:35

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-2kanFRK1NckAvxtiuMwx3w< at >public.gmane.org <dsteffen-2kanFRK1NckAvxtiuMwx3w< at >public.gmane.org< 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-

Re: dispatch_suspend() does not affect childqueues

Michael Roitzsch — 2012-08-06T10:46:15

Hi Daniel,


I knew that it was non-preemptive, but I was not aware it was also asynchronous. But the manpage describes it that way, so I should have known.


That was the missing bit to complete my mental picture. Thanks a lot for your explanation.

Michael

Re: dispatch_suspend() does not affect childqueues

Daniel A. Steffen — 2012-08-05T20:14:29

Michael,

On Aug 5, 2012, at 10:06, Michael Roitzsch <mroi-IG//nw+yl+iQIjdd1DhZXWfrygkm6VTR< at >public.gmane.org> wrote:


they are not, but unless dispatch_suspend(B) is executed from B itself, suspension is asynchronous and non-preemptive, i.e. suspension only takes effect when queue state is checked before the next item on B is executed (but does not affect the current item on B).

Importantly, because of the way target queues work, this means that many items on queue A can execute after the call to dispatch_suspend(B) before B actually becomes suspended (queue A as a whole is a single workitem on queue B so queue A may stay the "current item" on queue B for many items on A).

If you need to know exactly when queue suspension takes effect you need to execute dispatch_suspend on the queue itself.

HTH

Daniel