I have a scenario where a ruby extension module starts real/os/heavy-weight
threads that may call back to ruby. As far as I understand the ruby
interpreter itself is not thread safe. How can I handle this thread-safety
problem?
Cheers,
Thomas
I have a scenario where a ruby extension module starts real/os/heavy-weight
threads that may call back to ruby. As far as I understand the ruby
interpreter itself is not thread safe. How can I handle this thread-safety
problem?
Cheers,
Thomas
Hi,
At Thu, 4 Sep 2003 19:45:24 +0900, Thomas Sondergaard wrote:
I have a scenario where a ruby extension module starts real/os/heavy-weight
threads that may call back to ruby. As far as I understand the ruby
interpreter itself is not thread safe. How can I handle this thread-safety
problem?
Run the ruby interpreter in a particular os-thread, and use
system provided queue.
–
Nobu Nakada
The general solution for any threaded code making calls to a non-thread
safe library is to do one of the following:
(a) Make calls into the library (callbacks in your case) from
only a single thread.
or (b) Serialize calls to the library by using a mutex of some type.
On Thu, 2003-09-04 at 06:45, Thomas Sondergaard wrote:
I have a scenario where a ruby extension module starts real/os/heavy-weight
threads that may call back to ruby. As far as I understand the ruby
interpreter itself is not thread safe. How can I handle this thread-safety
problem?
“Beware of bugs in the above code; I have only proved it correct,
not tried it.” – Donald Knuth (in a memo to Peter van Emde Boas)
The general solution for any threaded code making calls to a non-thread
safe library is to do one of the following:(a) Make calls into the library (callbacks in your case) from only a single thread.
or (b) Serialize calls to the library by using a mutex of some type.
Got it!
Thomas
Run the ruby interpreter in a particular os-thread, and use
system provided queue.
Could you give me an example of such a system provided queue?
Cheers,
Thomas