On Mon, Jan 24, 2011 at 10:24 AM, Matt Massicotte <massico...@apple.com> wrote: > My guess is that most problems need a thread-safe mechanism, where > manipulating an array is just one part of a more complex system. Pushing the > details of the thread-safety into the array just hides the problem, and will > likely trade more locking for possibly simpler code. > > Which could be a very good trade, don't get me wrong. I'm not trying to > knock your implementation at all.
In some cases, it's a great trade. It's just not a trade-off you want to make for *all* access, which is why concurrent-threaded Ruby impls like JRuby and MacRuby don't make that guarantee for Array, Hash, etc. Of course, regular C Ruby isn't concurrent-threaded, so they have had little motivation to do *anything* to improve the state of concurrent programming on Ruby, like adding thread-safe collections or simpler synchronization mechanisms. > I think the actual underlying problem here is Queue#apply's rdoc entry. > Manipulating a non-thread-safe data structure (which is all of Foundation's > collection classes) in an apply is a bug and even worse a conceptual error. > Where do you open bugs on the dispatch gem? Queue#apply is actually defined in gcd.c in MacRuby's code, so this would be a MacRuby bug. I'd have filed it, but I wasn't sure if I was missing something about MacRuby's Array and thread-safety. - Charlie _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
