On Mon, Jan 24, 2011 at 11:39 AM, Jordan K. Hubbard <j...@apple.com> wrote: > FWIW, we've tried this same approach experimentally (use a per-object serial > queue behind the scenes to implement an async setter / sync getter model) > over in CoreFoundation land, and it seemed to work reasonably well for the > most part. We ran into some compatibility issues with a few of the methods > which just didn't lend themselves to a thread-safe object model, enough that > we couldn't simply do this as a completely transparent solution, but it > mostly Just Worked and I think MacRuby (or, for that matter, JRuby) could do > something very similar and probably get away with it since Ruby > arrays/hashes/strings aren't quite so inclined to hand pointers to their > internal state around to clients of the API. Laurent doesn't exactly agree > with me since he's still focused on performance, but I think it should > definitely be possible to declare a Ruby object as "contended" in some way > such that everything then goes through a serial queue implicitly to access it > - I'm not saying this sh > ould be true for every object, just the ones for which you need thread > safety.
I'd be extremely surprised if the overhead frrom making an object thread safe with a queue wasn't much higher than simply synchronizing all access with normal low-level locking primitives. It might be useful to transparently proxy all calls targeting a specific object through a queue-based delegator (as I believe you or someone has rigged up in the Dispatch gem), but I'd be very surprised if it were a good generally-applicable thread-safety mechanism for mutable state. Sometimes you just need to use locks. - Charlie _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
