Hi folks,
just a quick note (followed by a question) to let you know that my GCD 
rendition of ruby 1.9's most used feature – Fibers, is nearing completion. Code 
here:

https://github.com/alskipp/MacrubyFibers

Currently passes 51 expectations from the fiber spec. 3 failures, all related 
to raising exceptions, 2 of which can't be solved just yet as Macruby doesn't 
raise LocalJumpError for errant procs. The final test failure I'd like to fix, 
so here's the question…

When executing code on a serial dispatch queue, how can I raise an exception on 
the main queue? The following works in an Xcode project:

Dispatch::Queue.new('serial_queue').async do
    Dispatch::Queue.main.sync do
        raise "Exception from #{Dispatch::Queue.current}"
    end
end
#> Exception from com.apple.main-thread (RuntimeError)

My assumption is that this works because it is executed within an application 
run loop. The same code does not work if invoked directly by Macruby, 
presumably due to the lack of an application run loop, Macruby exits before the 
Exception can be raised on the main queue, sometimes resulting in a 
EXC_BAD_ACCESS crash.

Is there an alternative approach? 

Cheers,
Al


On 10 Jan 2012, at 18:44, Joshua Ballanco wrote:

> Hey Alan,
> 
> Awesome! I haven't had a chance to go through the code in detail, but I like 
> the general approach. I'll definitely be looking into this in more detail 
> later, but for now I just wanted to let you know that there are specs for 
> Ruby 1.9's fibers in the MacRuby repo at 'spec/frozen/library/fiber'. It 
> would be interesting to see how many of them pass with your implementation.
> 
> Cheers,
> 
> Josh
> On Thursday, January 5, 2012 at 10:36 AM, Alan Skipp wrote:
> 
>> Hi everyone,
>> I've had a go at implementing Fibers using dispatch queues. The code can be 
>> found here:
>> 
>> https://gist.github.com/1565393
>> 
>> Inspiration was taken from the following ruby 1.8 Fibers implementation: 
>> https://gist.github.com/4631
>> 
>> The implementation of Fiber.yield currently relies upon a hash stored as a 
>> class variable. This is hopefully just a temporary solution to get things 
>> started. The hash is always accessed through a serial queue (so it should be 
>> thread safe) and dead fibers are removed after use. There are a couple of 
>> GCD functions that look like they could be used to solve this problem: 
>> 'dispatch_queue_set_specific' and 'dispatch_set_context'. Though I'm not 
>> sure how to use these from Macruby. If anyone has any experience using 
>> either of those GCD functions I'd be interested in learning more.
>> 
>> The major omission currently is the lack of a 'transfer' method. I've 
>> pondered this quite a bit, but I've yet to come up with a solution. It is 
>> quite possible that the way I've written the Fiber class prevents a 
>> successful implementation of a 'transfer' method - but I've not given up 
>> just yet. If anyone has a cunning plan on how to achieve it, that would be 
>> great.
>> 
>> I've tested all the examples here:
>> http://pragdave.blogs.pragprog.com/pragdave/2007/12/pipelines-using.html
>> 
>> and they all seem to work, plus I've included a few tests in the gist.
>> The test which creates a fiber from Fiber.current, causes macruby to crash, 
>> but I don't know why - it doesn't cause a crash when invoked normally 
>> outside of minitest.
>> 
>> From my limited tests, everything other than the 'transfer' method appears 
>> to be working, but feedback would be welcome if you discover any problems.
>> 
>> Al
>> _______________________________________________
>> MacRuby-devel mailing list
>> MacRuby-devel@lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> 
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Reply via email to