[MacRuby] #447: GCD Crashes
#447: GCD Crashes ------------------------------+--------------------------------------------- Reporter: pete@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: ------------------------------+--------------------------------------------- I've been playing with the GCD support in 0.5, and I can get it to misbehave consistently with a fairly simple script (attached.) Various things happen when this script is run. Sometimes I get a crash with the assertion below, sometimes I get a seg fault. Assertion failed: ((arity.max == -1) | | (argc <= arity.max)), function !__rb_vm_fix_args, file dispatcher.cpp, line 29. Sometimes it runs mostly ok, but spits out NaN instead of the correct value at random intervals. Something to do with the block being prematurely garbage collected perhaps? -- Ticket URL: <http://www.macruby.org/trac/ticket/447> MacRuby <http://macruby.org/>
Hi Pete, I imagine that this bug is similar to one I posted (420). I was getting similar behaviour and things much improved when I unrolled the loop. Maybe you could try that? (or try what i suggest below). I am waiting with bated breath to see Laurent's GCD code in the macruby version of Sinatra. I imagine that it is actually quite hard to turn ruby blocks into C blocks - normally everything would be copied to the stack with C blocks - unless manually copied to the heap - but probably in macruby they have to be immediately copied to the heap. And then what to do with all the scoped (but in C static) variables? In C there are complicated inferred return block types which sometimes work, automatic releases sometimes, sometimes manual releases are necessary of queues (i.e GCD does not use GC) - it all seems rather complicated. There is a note somewhere I believe in the macruby gcd code about how it might be bad to access instance variables from a queue - none the less when using Laurent's web_server.rb code as model - the threading bit - and doing something similar in GCD - I got something working ok. Using threads (as per the example) and GCD I could get some speed improvements - however on a 2 core machine - those improvements were not much - i actually don't expect that much on only 2 cores - since there is a hell of a lot of other threading happening (eg GC) even if we don't consider the demands that the rest of the OS is putting on the processor. So with 2 cores I found best results to limit to two GCD serial queues. cpuCount = NSProcessInfo.processInfo.processorCount is a helpful command in this regard. I would be very interested to see your results if you try this out. One thing to watch out for variable allocations within the queue block - the variables might not be instantly available (like the next line).
From what i have read there are many resources in the OS which can stall when there are too many processes trying to access them - so perhaps a good way in the future is actually to wrap all resource access in semaphores - adjusted by cpu count.
Cheers, J On Mon, Nov 23, 2009 at 1:27 AM, MacRuby <ruby-noreply@macosforge.org>wrote:
#447: GCD Crashes
------------------------------+--------------------------------------------- Reporter: pete@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: MacRuby 0.5 Component: MacRuby | Keywords:
------------------------------+--------------------------------------------- I've been playing with the GCD support in 0.5, and I can get it to misbehave consistently with a fairly simple script (attached.)
Various things happen when this script is run. Sometimes I get a crash with the assertion below, sometimes I get a seg fault.
Assertion failed: ((arity.max == -1) | | (argc <= arity.max)), function !__rb_vm_fix_args, file dispatcher.cpp, line 29.
Sometimes it runs mostly ok, but spits out NaN instead of the correct value at random intervals.
Something to do with the block being prematurely garbage collected perhaps?
-- Ticket URL: <http://www.macruby.org/trac/ticket/447> MacRuby <http://macruby.org/>
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Hi John, On Nov 23, 2009, at 1:03 AM, John Shea wrote:
I imagine that it is actually quite hard to turn ruby blocks into C blocks - normally everything would be copied to the stack with C blocks - unless manually copied to the heap - but probably in macruby they have to be immediately copied to the heap. And then what to do with all the scoped (but in C static) variables? In C there are complicated inferred return block types which sometimes work, automatic releases sometimes, sometimes manual releases are necessary of queues (i.e GCD does not use GC) - it all seems rather complicated.
Did you mean the other way around? You seem to be discussing how to turn C blocks into Ruby blocks. Regardless, if you look at the GCD code you'll see that he sidesteps the issue, by passing the ruby block as a context pointer to a gcd_f function-based API. -- Ernie P.
Did you mean the other way around? You seem to be discussing how to turn C blocks into Ruby blocks.
hmmm? no that was not my intent. No I assume at some stage the ruby block has to be turned into a C block with associated scope - and from my limited knowledge on GCD that does not seem so easy. But Ernie - I'd love for you to explain how its all done! ;-). I mean if you have the time - it would be great to know maybe on pseudo code/architectural level how it all works. ruby block to c block, __block vars, scope etc, etc, I am a bit scratching in the dark here. Cheers, John
Hi John, On Nov 23, 2009, at 12:55 PM, John Shea wrote:
No I assume at some stage the ruby block has to be turned into a C block with associated scope - and from my limited knowledge on GCD that does not seem so easy.
Again, I think I'm still missing your point. In the context of GCD, this is a non-issue since you don't *have* to use C blocks. Instead, GCD provides a function pointer + context pointer API, which is what MacRuby uses: http://github.com/masterkain/macruby/blob/master/gcd.c
if (RTEST(synchronous)){ dispatch_sync_f(RQueue(self)->queue, (void *)block, rb_queue_dispatcher); } else { dispatch_async_f(RQueue(self)->queue, (void *)block, rb_queue_dispatcher); }
That is, C just treats the Ruby block as a data pointer. -- Ernie P.
Hi again, thanks for the code .. I am actually not trying to make a point - just trying to learn, and start a discussion that leads to learning. since the code below means nothing to me - thats probably a good place for me to start. Cheers, J On Nov 23, 2009, at 9:58 PM, Ernest N. Prabhakar, Ph.D. wrote:
Hi John,
On Nov 23, 2009, at 12:55 PM, John Shea wrote:
No I assume at some stage the ruby block has to be turned into a C block with associated scope - and from my limited knowledge on GCD that does not seem so easy.
Again, I think I'm still missing your point. In the context of GCD, this is a non-issue since you don't *have* to use C blocks. Instead, GCD provides a function pointer + context pointer API, which is what MacRuby uses:
http://github.com/masterkain/macruby/blob/master/gcd.c
if (RTEST(synchronous)){ dispatch_sync_f(RQueue(self)->queue, (void *)block, rb_queue_dispatcher); } else { dispatch_async_f(RQueue(self)->queue, (void *)block, rb_queue_dispatcher); }
That is, C just treats the Ruby block as a data pointer.
-- Ernie P.
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
#447: GCD Crashes ------------------------------+--------------------------------------------- Reporter: pete@… | Owner: lsansonetti@… Type: defect | Status: closed Priority: major | Milestone: MacRuby 0.5 Component: MacRuby | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Changes (by lsansonetti@…): * status: new => closed * resolution: => fixed Comment: Should be fixed in r3056. -- Ticket URL: <http://www.macruby.org/trac/ticket/447#comment:2> MacRuby <http://macruby.org/>
participants (3)
-
Ernest N. Prabhakar, Ph.D.
-
John Shea
-
MacRuby