Question

I’m writing a C extension, providing an interface between Ruby and an asynchronous I/O library. When running the tests over my code, I frequently get errors including (but not limited to):

[BUG] cross-thread violation in rb_thread_schedule()

Asynchronous IO means my C extension will need to deliver messages to ruby from multiple threads (not the main interpreter thread). How do I avoid these thread-safety violations, in the process?

Answer 1

For ruby 1.8.x the only way to avoid the error is the obvious one — only invoke the Ruby/C API from the main interpreter thread. I believe this applies to ruby 1.9.x as well, but I haven’t worked with it and don’t know how its native thread support might change things. Instead of having multiple native threads directly invoke the API, you need to use the producer/consumer pattern to deliver requests from your secondary native threads to your code in the main interpreter thread. And ideally do this while not unnecessarily blocking other Ruby green threads. If you look at the ruby implementation, the ruby green thread scheduler is essentialy a select() loop. This suggests the following overall structure:

• Create a pipe or other IPC mechanism which provides a real select()-able file descriptor.
• Spawn native threads and provide them with the write end of the pipe.
• In the main interpreter thread, enter an event loop which calls rb_thread_wait_fd() on the read end of the pipe. This will allow the ruby green thread scheduler to run other green threads.
• When your secondary native threads have requests for the main thread, they queue them and also write to the pipe, waking up the green thread running your event loop.

See rb_io_sysread() (implementation of IO#sysread) for what is probably the simplest clean IO-using function in the ruby code base.