Forum: Ruby Waking ruby thread on external event

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2006-03-01 03:32
(Received via mailing list)
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
F0223b1193ecc3a935ce41a1edd72e42?d=identicon&s=25 zdennis (Guest)
on 2006-03-01 03:37
(Received via mailing list)
Bill Kelly wrote:

>
> (*) 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.
>
>

Can't you do this the other way around as well.... write C/C++ extension
for ruby which stores
reference to ruby thread, and call it from c++ code which would wake
your ruby thread?

Zach
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2006-03-01 05:29
(Received via mailing list)
Bill Kelly wrote:
> 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.)

Can the ruby thread just Thread.sleep, and wait for the C++ code to call
rb_thread_wakeup() or whatever it is that implements Thread#wakeup ?
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2006-03-01 06:19
(Received via mailing list)
From: "zdennis" zdennis@mktec.com
> for ruby which stores reference to ruby thread, and call it from c++ code
> which would wake your ruby thread?

All ruby threads run on a single OS thread, and the ruby
interpreter isn't generally reentrant, as I understand it.

So I don't know how to put one ruby thread to sleep on something
like a boost::condition variable without sleeping the whole OS
thread ruby runs on, thus blocking all ruby threads.

And I also don't know if I can call straight into ruby's eval.c
from a non-ruby OS thread, to try to fiddle with the ruby threads
and the ruby scheduler to wake my ruby thread up - due to the
ruby interpreter not being reentrant.  (Without hacking the ruby
source code, at any rate.)  Although if anyone knows to the
contrary, that an external OS thread can safely wake up a
ruby thread that'd be great.

I may end up trying the UDP approach.  It's got to be better
than my initial make-it-work implementation, where my ruby
threads sleep for 1/10 second and check a queue.

But if anybody knows another way .... ?  :)


Regards,

Bill
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2006-03-01 08:30
(Received via mailing list)
From: "Joel VanderWerf" <vjoel@path.berkeley.edu>
>
> Can the ruby thread just Thread.sleep, and wait for the C++ code to call
> rb_thread_wakeup() or whatever it is that implements Thread#wakeup ?

Hi - somehow i'd not seen your reply.  Thanks.

Hmm...

VALUE
rb_thread_wakeup(thread)
    VALUE thread;
{
    rb_thread_t th = rb_thread_check(thread);

    if (th->status == THREAD_KILLED)
        rb_raise(rb_eThreadError, "killed thread");
    rb_thread_ready(th);

    return thread;
}

I don't suppose this could be called from a different OS thread
than ruby's.

And the ruby interpreter may be waiting in a select() call when
I need to wake up my ruby thread.

Ah, well.. Maybe UDP is the way to go...   <smile>


Regards,

Bill
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2006-03-01 08:53
(Received via mailing list)
Bill Kelly wrote:
> rb_thread_wakeup(thread)
>
> I don't suppose this could be called from a different OS thread
> than ruby's.

Not necessarily such a problem. rb_thread_wakeup() doesn't muck around
with any data structures that the thread scheduler uses. It just sets a
couple of fields in the thread object. So there's a race condition, and
a breaking of encapsulation, and a gnashing of teeth. But other than
that, possible.

> And the ruby interpreter may be waiting in a select() call when
> I need to wake up my ruby thread.

Oh. That's the real problem. You could keep one thread in a loop {sleep
epsilon}, but that's back to square one.

> Ah, well.. Maybe UDP is the way to go...   <smile>

Sounds like it is.
This topic is locked and can not be replied to.