On Wed, Jan 26, 2011 at 4:45 PM, Laurent Sansonetti <lsansone...@apple.com> wrote: > Hi Charles! > Sorry for the late response. > As others have noted, in this snippet, #apply is called on a sequential > queue (queues created by Queue.new are always sequential), therefore there > shouldn't be any problem here. If the queue was concurrent, however, there > would be a thread safety issue. > I think this rdoc snippet should be rewritten to avoid confusion.
Yup, I understand now. Thank you! > I see that you're wrapping a GCD-like interface in JRuby, it's very cool! I > assume you want your interface to be cross platform, but in the case of > JRuby running on Mac OS X, maybe we can extract our code as a C extension, > this way JRuby would use the "system" GCD. Maybe we can also work together > on creating a good test/spec suite for the GCD interface, because it's > currently lacking. To be honest I'm more and more downbeat about C extensions. On JRuby, we have opted to disallow C extensions from running concurrently, since there's just too many extensions that mutate global state. They also make it impossible to spin up multiple JRuby instances in the same JVM, since ALL C extensions hold references to a specific JRuby runtime or classes it contains in global state (i.e. no extensions out there are MVM-safe). So there are certainly other possiblities: 1. FFI. The libdispatch APIs are all C-based and seem to be pretty consistent. A single FFI binding might work for everyone including MRI. 2. Attempt to build off Java/Cocoa integration, as seen in this attempt: http://pixel.recoil.org/code/rococoa/index.html. I don't know how reliable that integration is though, or if Apple is going to continue maintaining it. A C extension would probably be a "last resort" since it has many limitations. re: testing: Yes! Are there many tests for this yet? I have not looked for them, so I have no idea. I'd love to see a complete suite (or at least complete for the highest-level surface area of functionality) that we could all try to meet. - Charlie _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
