B
Bill Kelly
Hi,
I have Ruby embedded into a multithreaded C++ app. It's easy for
a C++ thread to wait for an event from a Ruby thread.(*) But I'm
looking for ways to allow a Ruby thread to sleep until an event
from a C++ thread is posted.
My application is cross-platform so my solution needs to work on
Windows and OS X.
So far all I can think of, without hacking ruby itself, is to
open a TCP or UDP socket, and have the Ruby thread select() on
the socket. Then the C++ side can fire a packet at the socket to
wake the ruby thread up.
Can anyone think of a simpler way? I haven't measured the overhead
yet, but offhand it seems overkill to send a packet through the IP
stack to do the work of a condition variable. (But yes I do need
to actually measure it.)
(*) Sleeping in C++ for an event from a Ruby thread: The C++ thread
sleeps on a boost::condition variable. The Ruby thread invokes a C
extension method which notify()'s the condition variable. Simple
enough in this direction.
Any thoughts appreciated,
Thanks,
Bill
I have Ruby embedded into a multithreaded C++ app. It's easy for
a C++ thread to wait for an event from a Ruby thread.(*) But I'm
looking for ways to allow a Ruby thread to sleep until an event
from a C++ thread is posted.
My application is cross-platform so my solution needs to work on
Windows and OS X.
So far all I can think of, without hacking ruby itself, is to
open a TCP or UDP socket, and have the Ruby thread select() on
the socket. Then the C++ side can fire a packet at the socket to
wake the ruby thread up.
Can anyone think of a simpler way? I haven't measured the overhead
yet, but offhand it seems overkill to send a packet through the IP
stack to do the work of a condition variable. (But yes I do need
to actually measure it.)
(*) Sleeping in C++ for an event from a Ruby thread: The C++ thread
sleeps on a boost::condition variable. The Ruby thread invokes a C
extension method which notify()'s the condition variable. Simple
enough in this direction.
Any thoughts appreciated,
Thanks,
Bill