You're right, no ivars are being written in concurrent threads in the bug report code. However, in the NSURLConnection example, two ivars are used. The is the code to execute (the block). The second is the data buffer that will be changed as the HTTP response data returns.
In either case, there are potential problems. If there is a context switch while @block is being reassigned, the code in the block may be incomplete at the time of the switch. I don't know. In the case of the buffer, it is very likely to be stepped on in a context switch as the whole point of executing HTTP GETs in parallel is to switch context while blocked on network response. I only know this because I'm in the middle of (not yet successfully) trying to solve the same problem with native threads. Steve On Jan 17, 2010, at 10:34 PM, Joshua Ballanco wrote: > > I'd have to look at the NSURLConnection example again, but in the code from > the bug report, there's no unsafe variable access in the Ruby code. Each Bar > holds a reference to its own Foo in @foo, and we're dispatching to multiple > Bars in turn. If you run that sample (you might need to tweak some of the > parameters, depending on your machine) I think you'll find a fun error > message that indicates this is definitely a MacRuby bug. :-) > > Cheers, > > Josh > > > On Jan 17, 2010, at 10:25 PM, steve ross wrote: > >> But... both examples show multiple threads accessing a single instance >> variable without taking any precautions to make the access atomic. Could it >> be that kind of concurrency issue? >> >> Steve >> >> On Jan 17, 2010, at 6:01 PM, Joshua Ballanco wrote: >>> >>> Hey Darin, >>> >>> Looks like you're hitting https://www.macruby.org/trac/ticket/511 >>> >>> Cheers, >>> >>> Josh >> _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
