Hey Ernest, Oh okay, and now that code makes more sense :-D I'm out of my depth here as I really don't understand GCD nor have I looked into your GCD library.
I can only think of one thing, really, and that is to make "i" available as a block parameter. The variable would then be block-local, but you would still enjoy the benefits of closures. As I understand it, you don't want any mutations to "i" to exist outside the thread you're executing. My 2 cents. Sorry if it is not useful to you. Rob ---- http://robgleeson.github.com Website http://github.com/robgleeson GitHub r...@flowof.info E-Mail On 15 Jul 2010, at 22:38, Ernest N. Prabhakar, Ph.D. wrote: > Hi Rob, > > On Jul 15, 2010, at 2:34 PM, Rob Gleeson wrote: >> Hey again, >> >> Sorry just had another idea - since it seems like you don't want the >> enclosing scope/context to be evaluated in a thread, you could try using >> instance_eval in a "blank" context where you won't have surrounding >> variables available to your block. >> >> That, and passing arguments to the block as parameters should work but I'm >> way out of my depth as far as GCD goes. > > > Um, I don't think I'm following you. > > The real issue with GCD is that it expects blocks to be closures, which > capture their local environment. For the most part, we can pass Ruby blocks > and it will "do the right thing" -- but with one caveat. > > Ruby allows read-write access to captured variables, but GCD can't, because > the block may be executed asynchronously long after the current scope is > destroyed. Therefore, we hack the Ruby runtime to 'const-ify' any local > variables that are present in a GCD block. > > We don't want to remove -any- reference to local variables, as that would > defeat the benefit of using closures. > > -- Ernie P. > >> >> Rob >> ---- >> http://robgleeson.github.com Website >> http://github.com/robgleeson GitHub >> r...@flowof.info E-Mail >> >> >> On 15 Jul 2010, at 22:29, Rob Gleeson wrote: >> >>> Hey ernest, >>> >>> I haven't got any experience with GCD but wouldn't it make more sense if >>> block arguments were received as parameters to the block? >>> This would make the variables block-local. >>> >>> Dispatch::Queue.new("i").sync { |i| # block local 'i' } >>> >>> Remember blocks in Ruby are closures, too. >>> >>> Rob >>> ---- >>> http://robgleeson.github.com Website >>> http://github.com/robgleeson GitHub >>> r...@flowof.info E-Mail >>> >>> >>> On 15 Jul 2010, at 21:47, MacRuby wrote: >>> >>>> #795: GCD inconsistently copies local variables inside blocks >>>> ----------------------------------------+----------------------------------- >>>> Reporter: ernest.prabha...@… | Owner: lsansone...@… >>>> >>>> Type: defect | Status: new >>>> Priority: critical | Milestone: >>>> >>>> Component: MacRuby | Keywords: >>>> >>>> ----------------------------------------+----------------------------------- >>>> The expectation is that Ruby blocks will have their local variables copied >>>> before being passed to GCD, to avoid errors from accessing them after they >>>> are destroyed. >>>> >>>> However, that does not seem to always happen. For example: >>>> >>>> $ macruby -e 'i=0; Dispatch::Queue.new("i").sync {i = 42}; puts i' >>>> >>>> returns '0' as expected. However, this does not: >>>> >>>> $ macirb >>>> irb(main):001:0> i=0; Dispatch::Queue.new("i").sync {i = 42}; puts i >>>> 42 >>>> => nil >>>> >>>> It appears to be copied properly in the block_spec.rb test: >>>> >>>> it "should create const copies of dynamic (local) variables" do >>>> i = 42 >>>> @q.sync {i = 1} >>>> i.should == 42 >>>> end >>>> >>>> But not in the README.rdoc for the dispatch module (aka >>>> dispatch_methods.rb sample): >>>> >>>> n = 0 >>>> job = Dispatch::Job.new { n = 21 } >>>> job.join >>>> puts "n (after): #{n} => 0?!?" # [returns 21, not 0] >>>> >>>> Any suggestions? >>>> >>>> -- >>>> Ticket URL: <http://www.macruby.org/trac/ticket/795> >>>> MacRuby <http://macruby.org/> >>>> >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > 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
