llvm dev - Jan 2013 - [LLVMdev] Calling dispatch_async() within call to ExecutionEngine::runFunction()

My host app calls runFunction() on my JITed code. It, in turn, calls a C
function ("decode()") in the host app that then calls
dispatch_async(). The runFunction() call returns as expected, but the block
passed to dispatch_async() never gets called. The async block is supposed to
call a function pointer callback that was passed in to decode().

Everything is being called on the main queue.

Is it not possible to do this? Is something in LLVM actually aborting the
dispatch_async() execution of my block?

Thanks!

-- 
Rick

I have used libdispatch (on FreeBSD) from JIT'd code without any issues, so
I think your bug is elsewhere.

David

On 30 Jan 2013, at 07:43, Rick Mann wrote:
> My host app calls runFunction() on my JITed code. It, in turn, calls a C
function ("decode()") in the host app that then calls
dispatch_async(). The runFunction() call returns as expected, but the block
passed to dispatch_async() never gets called. The async block is supposed to
call a function pointer callback that was passed in to decode().
> 
> Everything is being called on the main queue.
> 
> Is it not possible to do this? Is something in LLVM actually aborting the
dispatch_async() execution of my block?
> 
> Thanks!
> 
> -- 
> Rick
> 
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Jan 30, 2013, at 0:43 , David Chisnall <David.Chisnall at cl.cam.ac.uk>
wrote:
> I have used libdispatch (on FreeBSD) from JIT'd code without any
issues, so I think your bug is elsewhere.
That's good to know, thanks. Puzzling, though. If I call the callbacks
directly, everything executes as you would expect (the stack grows to the last
callback, then unwinds, and runFunction() returns.

But the dispatch_async() block is never called at all. I don't know what can
cause this.

void
PDField::decode(PDPacket* inPacket,
                DecodeFieldCompletionProc inCompletionProc,
                void* inContext)
{
    NSLog(@"decodeField(%p, %p, %p, 0x%llX)", this, inPacket,
inCompletionProc, (uint64_t) inContext);
    NSLog(@"Field name: %s", mFieldName);
    NSLog(@"queue: %s",
dispatch_queue_get_label(dispatch_get_current_queue()));
    
    dispatch_async(dispatch_get_current_queue(),
    ^{
        NSLog(@"comp: %p", inPacket->mCompletionProc);
        inCompletionProc(this, inPacket);
    });
}

Output is:

2013-01-29 23:40:25.456 otest[66325:303] decodeField(0x106b09d20, 0x106b09d00,
0x106c90010, 0x0)
2013-01-29 23:40:25.456 otest[66325:303] Field name: packetMarker
2013-01-29 23:40:25.457 otest[66325:303] queue: com.apple.main-thread

Breakpoints set before dispatch and on first line inside the block, never stops
at the inside one.

-- 
Rick

On Jan 30, 2013, at 0:43 , David Chisnall <David.Chisnall at cl.cam.ac.uk>
wrote:
> I have used libdispatch (on FreeBSD) from JIT'd code without any
issues, so I think your bug is elsewhere.
Oh! I wonder if there's no run loop, because it's called from a unit
test. Of course.

Thanks!

-- 
Rick