Re: [MacRuby-devel] MacRuby and ARC was: Advice for Total Tyro
Hi Perry, On Tue, Oct 18, 2011 at 12:07 AM, Perry E. Metzger wrote: > On Mon, 17 Oct 2011 13:44:56 -0700 Matt Aimonetti > wrote: >> See my earlier reply, basically, you are right, it is technically >> possible to change the way MacRuby works to use an automatic >> reference counting approach. >> But it's far from being trivial. > > Wouldn't reference counting radically change the behavior of Ruby in > the presence of cycles though? It would no longer be exactly the same > language -- libraries that used cyclic data structures internally > would need to be rewritten. > Some people managed to have ref counting GCs that are able to deal with cycles. http://en.wikipedia.org/wiki/Reference_counting#Dealing_with_reference_cycles I also believe that CPython works similarly. Laurent ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] MacRuby and ARC was: Advice for Total Tyro
On Tue, 18 Oct 2011 10:04:37 +0200 Laurent Sansonetti wrote: > Hi Perry, > > On Tue, Oct 18, 2011 at 12:07 AM, Perry E. Metzger > wrote: > > On Mon, 17 Oct 2011 13:44:56 -0700 Matt Aimonetti > > wrote: > >> See my earlier reply, basically, you are right, it is technically > >> possible to change the way MacRuby works to use an automatic > >> reference counting approach. > >> But it's far from being trivial. > > > > Wouldn't reference counting radically change the behavior of Ruby > > in the presence of cycles though? It would no longer be exactly > > the same language -- libraries that used cyclic data structures > > internally would need to be rewritten. > > > > Some people managed to have ref counting GCs that are able to deal > with cycles. These techniques fall into a couple of categories: run a real GC every once in a while, or require user code changes (some of which could reduce safety guarantees). The latter technique in conjunction with reference counting is probably a great compromise in a C or Objective C context -- the environment already does lots of manual memory management and is already not safe. For something like Ruby, though, it feels much less clean. Using reference counting to reduce the number of sweep passes for a real GC would probably be fine, of course. That might reduce MacRuby's real memory runtime footprint a lot, too, as transiently used objects would vanish very fast. If I recall correctly, almost all objects never have more than one reference and die extremely fast. Perry -- Perry E. [email protected] ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] thread-safety and collections in macruby
In ObjC, the immutable collections are threadsafe. In macruby, are collections threadsafe to read only? ie, if I do this: a = [ ...] # an array that may or may not be changed b = a.dup # nowhere in the code is b ever used to add/delete/change an element is b thread-safe to read from multiple threads (queued operations/blocks)? also, is there any difference between doing b = a.dup and b = NSArray.arrayWithArray(a) Both result in class Array, so I assume there is no difference. Cheerio, Michael Johnston [email protected] ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] thread-safety and collections in macruby
Note, in my example I can also guarantee that none of the elements in b are going to be changed (for example, an array of strings) Cheerio, Michael Johnston [email protected] On 2011-10-18, at 10:17 PM, Michael Johnston wrote: > In ObjC, the immutable collections are threadsafe. > > In macruby, are collections threadsafe to read only? > > ie, if I do this: > > a = [ ...] # an array that may or may not be changed > > b = a.dup # nowhere in the code is b ever used to add/delete/change an element > > is b thread-safe to read from multiple threads (queued operations/blocks)? > > also, is there any difference between doing > > b = a.dup > > and > > b = NSArray.arrayWithArray(a) > > Both result in class Array, so I assume there is no difference. > > > > Cheerio, > > Michael Johnston > [email protected] > > > > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] thread-safety and collections in macruby
If you're not wring/changing the array no problems. But to be safe use Object#freeze... Terry Moore On 19/10/2011, at 6:26 PM, Michael Johnston wrote: > Note, in my example I can also guarantee that none of the elements in b are > going to be changed (for example, an array of strings) > Cheerio, > > Michael Johnston > [email protected] > > > > > On 2011-10-18, at 10:17 PM, Michael Johnston wrote: > >> In ObjC, the immutable collections are threadsafe. >> >> In macruby, are collections threadsafe to read only? >> >> ie, if I do this: >> >> a = [ ...] # an array that may or may not be changed >> >> b = a.dup # nowhere in the code is b ever used to add/delete/change an >> element >> >> is b thread-safe to read from multiple threads (queued operations/blocks)? >> >> also, is there any difference between doing >> >> b = a.dup >> >> and >> >> b = NSArray.arrayWithArray(a) >> >> Both result in class Array, so I assume there is no difference. >> >> >> >> Cheerio, >> >> Michael Johnston >> [email protected] >> >> >> >> >> ___ >> MacRuby-devel mailing list >> [email protected] >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
