[MacRuby-devel] Thread safety in apply example?

[Charles Oliver Nutter]

On Wed, Jan 26, 2011 at 4:45 PM, Laurent Sansonetti
<lsansonetti at 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