From: Ian Main <imain@...>
Date: 2000-02-24T00:30:41-08:00
Subject: [ruby-talk:01559] Re: Ruby thread scheduling buglet

On Thu, Feb 24, 2000 at 04:52:33PM +0900, Yukihiro Matsumoto wrote:
> Hi,
> 
> In message "[ruby-talk:01551] Ruby thread scheduling buglet"
>     on 00/02/23, Ian Main <imain@gtk.org> writes:
> 
> |You're going to like this one :)
> 
> Yes.  You even gave me a patch!  How pleasure it was.
> 
> |with the constant calling to sleep, it goes through this every call to
> |rb_thread_schedule ().  The thread that was sleeping, wakes up probably just
> |about every run through this function, so its set as the current thread.  It
> |then loops about, goes to sleep again, and somewhere in there the next
> |thread is run (thread 3 in our example), but then this one wakes up again
> |before any others have a chance to run, and the scheduling is reset.
> 
> Well, I wanted to give high priority to just awaked thread, but I
> guess it was too high.  To handle it properly, I have to implement
> more complex thread scheduler, so I can compromise, at least for now.

Yes, I had figured that was the case.  I had thought it was to provide more
reliable timers.. having the thread postponed in the queue would put delay
on top of the sleep() call.. but then in multitasking OS's you don't get
much of a guarentee anyway.

I was playing today a bit more with gtk and threads, and I found once you
get about 4 threads going on top of gtk, the respones is again slow..
looking at the setitimer stuff for scheduling, you set 50ms per thread,
which means you end up waiting 250ms for gtk redraws.

I had assumed lowering this value would cause the context switches to
consume more CPU, making the application more inefficient overall. However,
not liking assumptions, I gave it a test at 10ms, running a program similar
to the one I showed for the test (4 threads, and one in Gtk::main), and
requiring 1000000 iterations out of each thread, the runtime at 50ms and
10ms was nearly identical (23.6s versus 23.8s usertime), with the 10ms one
of course, keeping the UI much more interactive.

What do you think about setting it to 10ms ?

Ian