[ruby-talk:01560] Re: Ruby/GTK and the mainloop

On Thu, Feb 24, 2000 at 04:47:18PM +0900, Yukihiro Matsumoto wrote:
> Hi,
> 
> In message "[ruby-talk:01550] Re: Ruby/GTK and the mainloop"
>     on 00/02/23, Ian Main <[e-mail]> writes:
> 
> |Yes, what I did was change the idle () function:
> |
> |static gint
> |idle()
> |{
> |    struct timeval wait;
> |    
> |    wait.tv_sec  = 0;
> |    wait.tv_usec = 1000; /* 100ms */
> |    
> |    CHECK_INTS;
> |    if (!rb_thread_critical) rb_thread_wait_for(wait);
> |  
> |    return Qtrue;
> |}
> |
> |If I am correct, what ends up happening in rb_thread_wait_for (), is that it
> |calls thread_schedule with a timeout of (in this case) 100ms.  If there are
> |no other active threads, it sits in select for 100ms, and then returns to
> |give gtk a chance to run.  Changing the above to 10ms, means that gtk gets
> |control back faster (so long as no other ruby threads are running).
> 
> Since you don't need to run idle function when there's only one
> thread, you may use rb_thread_alone() to check threads.  It returns
> true if there is only one thread (main_thread).

Hmm, yes, this could improve matters.

> |GTK has good facilities for this.. from looking through ruby source code
> |again, it looks like ruby needs only:
> |
> |* The ability to watch file descriptors for read/write readiness.
> |* A timeout for sleep() and similar functions.
> |
> |What we can do is extrapolate that in the ruby core, so that when ruby needs
> |these facilities, it calls a specific function in ruby.  We then set it up
> |so that in the end these use function pointers, defaulting to the native
> |ruby versions.  A function in ruby could then allow us to override these
> |functions inside ruby, and in the case of the gtk bindings, they would
> |provide ruby-compatible wrappers around gdk_input_add (), and
> |gtk_timeout_add ().
> 
> Hmm, I have to participate in this discussion bit more seriously if
> core modification needed. :-)
> 
> I haven't get the picture well yet.  Two features above can solve the
> slow gtk problem?  Technically speaking, those features are fairly
> easy to implement, except we need to decide *good* API beforehand.

Yes, and I am glad to see you are interested, and want a good api :)  I
would be happy to work with you on this.

> |Yes, that's exactly why.  GTK is only getting a chance to refresh the screen
> |every 100ms, which is noticible when scrolling, or typing etc.
> 
> Gtk's idle() function called too often.  How about using
> gtk_add_timeout() again, like before?  What was the problem?

gtk_add_timeout () combined with rb_thread_alone () would probably be an
improvement.  The overall issue, is that you have 2 peices in a gtk/ruby
program, both of which usually assume they have complete control.  So what
you end up having to do is allow one to assume control, and then poll for
events (or runnable threads) in the other.

I personally don't like polling, so I'm trying to think of a way around
this.

With my perusal of the thread code today, I almost have my head around it
all.. there's still a few issues I need to figure out with respect to
extrapolating the main loop, so I'll look into resolving that in the next
few days.

Thanks,

	Ian


> 
> 							matz.