Reputation: 23024
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?
Upvotes: 5
Views: 665
Reputation: 4485
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:
select()
-able file descriptor.rb_thread_wait_fd()
on the read end of the pipe. This will allow the ruby green thread scheduler to run other green threads.See rb_io_sysread()
(implementation of IO#sysread
) for what is probably the simplest clean IO-using function in the ruby code base.
Upvotes: 7