Re: [ruby-gnome2-devel-en] Self-pipe for Ruby threads pushing blocks to main loop

[Drake W. <dr...@be...>]

Quoth Guillaume Cottenceau <gco...@gm...>, on 2007-11-20 16:03:02 +0100:
> As far as I understand the code, it seems to be the core of the
> solution found to the impossible cooperation between ruby's mainloop
> (the thing which schedules ruby threads) and glib's mainloop (the
> thing which triggers timeouts, idles, emit signals). As far as I know,
> there is no native collaboration mechanism between the two's, and
> that's the core of our problem;

The cooperation mechanism is (or was) the custom polling function,
which does at least bind the scheduling functions together.  The GLib
docs even refer to doing things this way: the doc for
g_main_context_set_poll_func says that "this function could possibly
be used to integrate the GLib event loop with an external event loop."

Unfortunately, Unixy platforms do not make integrating such things
with each other easy at all; the custom poll function sort of thing is
about the best you can do.  (Again, I haven't developed enough Win32
to be able to say anything about it there; perhaps it's easier there.)

> Unfortunately, this problem is going to get worse and worse, because
> processor occupancy during idle times is getting tracked more closer
> now that environment friendliness is a hype.

I consider it an issue of clarity.  When the semantics that you _mean_
are a combination of "wait until something happens" and "a new thing
to do counts as something happening", then that is what should be
implemented.  If you implement "check every N milliseconds for
something happening" instead, this is suboptimal, because that's not
really the semantics that were meant.  The processor having to wake up
incessantly is an unfortunate side effect.

> Here's how I understood the problem back then:
[light snip]
> Now, that doesn't explain the needs for this empty timeout. As often
> with Ruby, I have problems finding the API documentation, this time
> for rb_thread_select :/. Last time I asked for assistance here about
> Ruby API documentation, Masao indicated that README.EXT from ruby
> tarball is often useful to extension developers, but it seems to not
> document rb_thread_select. An assumption can be that rb_thread_select
> will not necessarily schedule all the threads, or that non main
> threads will somehow "lock" the main thread, hence the need to pump an
> event into the file descriptors lists to force rb_thread_select to
> return - but that doesn't really make sense anyway..

The reason I used a pipe rather than some other form of communication
between Ruby threads is that I didn't see another way to prevent
desynchronization conditions where the wakeup signal would get lost,
but that may have been based on my previous conservative
interpretation of the ruby atomicity guarantees.  Instead, it may be
possible to just check for the presence of main loop blocks before
doing the rb_thread_select and set the timeout to zero if there are
any there.

> Now, according to rg2's svn, Kouhei recently switched from the custom
> poll function approach, to installing a GSource (which calls
> rb_thread_schedule from the "prepare" callback).
> 
> Working file: rbglib_mainloop.c
> r2707 | ktou | 2007-11-17 04:50:39 +0100 (Sat, 17 Nov 2007) | 2 lines
> 
> * src/rbglib_mainloop.c: used GSource not poll func overriding.

That sounds like a disaster.  (Custom GSources are designed rather
poorly, in my opinion, though that's probably the fault of the
platform(s).  It basically forces the use of unwanted timer polling.)

> I see that the "prepare" callback currently sets the returned timeout
> value to 1 millisecond, which would indicate that the source tells GTK
> that it needs to be rechecked after 1 millisecond only. If I'm
> understanding this correctly (trunk untested), it means rg2 is almost
> doing active-wait now :/

strace says that's exactly what's happening when I run a simple test
program that uses GTK+ with r2712.

  poll([{fd=5, events=POLLIN}], 1, 1)     = 0
  select(4, [3], [], [], {0, 0})          = 0 (Timeout)
  ioctl(5, FIONREAD, [0])                 = 0
  {infinitely repeating}

The interrupt signal doesn't work properly anymore either, though that
may be an artifact of something else.  I rather hope this will be
backed out, because I think a GSource is a much more broken way to
integrate with Ruby threads than the custom poll function, but perhaps
they have another idea that I haven't anticipated.

> I think that the status of non japanese developers/contributors on rg2
> should be clarified. It is not fair that we are considered second-tier
> citizens, or then let's just consider rg2 is a japanese developers
> only project and we'll be able to make decisions according to that
> fact. You see that here, this thread discussed that matter; if you
> make some related source code modifications, we should not be left
> outside.

Alas, a language barrier is not really anyone's fault, and there's no
clear solution.  x.x  Maybe we should get translators to act as
gateways between the lists?  c.c

> Guillaume Cottenceau - http://zarb.org/~gc/

   ---> Drake Wilson