Self-pipe for Ruby threads pushing blocks to main loop

Hi Kouhei,

Thanks for your reply.

Kouhei, would you be so kind in participating to the discussion, at
least explaining what’s your modification, what problem are you trying
to solve, and its impact on multi-threading in rg2 applications if you
know it?

If you find any problems, please make a sample script that
shows the problem and the script should not be pseudo code.
It’s too hard for me to participate your discussion without
trying the current implementation in English. I don’t good
in English as you know.

I am personally very much in favor of the “show me the code” approach
instead of hours of useless speak. But that’s slightly more
complicated here:

  • there’s no need to show a sample script which shows the
    multithreading problem, it’s been done already; everyone knows that
    rg2 applications cannot be used with Ruby threads safely without
    workarounds/tricks; we’re currently in the step further: how to solve
    this?

  • the multithreading problem of rg2 is a long standing issue, which is
    still not solved; one needs to understand what’s going on and propose
    solutions together with patches; ideas are not always inferior to
    patch, they are sometimes needed to come up with clever patch,
    particularly with tough problems like multithreading is; you cannot
    expect everyone to always show a patch…

  • Drake sent a patch, but you haven’t commented about it, Mathieu also
    showed his Ruby solution; you have commited a change in the same code
    location, you could have quickly informed about it…

I think we’re all ok to consider that english is not so easy for some
japanese developers. But most of the world developers are not native
english speaker, including a lot of people here, and myself by the
way. I think some minimum involvement in english is needed to have
things going on, or only Masao and you will be able to contribute to
rg2. If japanese developers who lead rg2 don’t follow some of this
list (not all, only when there are patches like in this thread, or for
important issues), let’s rename it to “ruby-gnome2-app-devel-en”
because actually no rg2 devel can happen here.


Guillaume C. - Guillaume Cottenceau

Quoth Mathieu B. [email protected], on 2007-11-22 01:28:01
+0100:

Drake, does the following work with your patch (I don’t have time to
test it myself right now, sorry):

(Just for the record, let me note again that my original patch would
have to be cleaned up a bit before actually being viable for use. I
posted it so that the basic idea could be seen and discussed with an
available prototype implementation in C rather than nothing… and
that’s the last redundant disclaimer I’ll give. nod)

ruby -r gtk2 -e “Thread.new { while true; sleep 1; puts ‘yes’; end };
Gtk.main”

As I understand what’s happening, only calls to your
GLib.main_thread_do_async write to the pipe and thus only them can wake
up the main loop. So threads doing non-gtk stuff would not wake up the
mainloop and ruby would not be able to switch to them. Am I missing
something?

The custom poll function uses rb_thread_select, not raw select. (This
was also true before.) This tells the Ruby interpreter to block the
current thread only, and queue it as waiting for the FDs in the call.
That means that if other Ruby-level threads are runnable, they will
still be scheduled; only if no other threads are runnable will the
process actually block.

So yes, that should work fine. I seem to recall finding that to be
true by experiment also; if it doesn’t work on your system, then we’d
want to find out why, of course.

Mathieu

—> Drake W.