[#1215] Tk widget demo; English Tk docs?; Java 1.2 Swing — "Conrad Schneiker" <schneiker@...>
Hi,
[#1218] Trivial FAQ bug — Dave Thomas <Dave@...>
[#1229] A vote for old behavior — Dave Thomas <Dave@...>
[#1232] Any FAQ requests, updates, ... — Dave Thomas <Dave@...>
[#1233] Singleton classes — Dave Thomas <Dave@...>
[#1263] Draft of the updated Ruby FAQ — Dave Thomas <Dave@...>
[#1307] Ruby/GTK 0.23 released — Hiroshi IGARASHI <igarashi@...>
Hi all,
From: Hiroshi IGARASHI <igarashi@ueda.info.waseda.ac.jp>
From: "Conrad Schneiker" <schneiker@jump.net>
On Fri, Feb 18, 2000 at 09:37:27PM -0500, Yasushi Shoji wrote:
[#1322] FAQ: Ruby acronyms — "Conrad Schneiker" <schneiker@...>
In the spirit of TABWTDI (there are better ways to do it), I'd like to
[#1341] Vim syntax file — Mirko Nasato <mirko.nasato@...>
Hi,
On Mon, Feb 14, 2000 at 05:44:39PM +0100, Mirko Nasato wrote:
[#1354] Say hi (bis) — Pixel <pixel_@...>
hi all,
[#1355] nice sample for functional stuff — Pixel <pixel_@...>
what about having map in standard (and map_index too)?
[#1373] Ruby Language Reference Manual--Glossary — "Conrad Schneiker" <schneiker@...>
I was going to print the Ruby Language Reference Manual when I noticed that
[#1376] Re: Scripting versus programming — Andrew Hunt <andy@...>
Conrad writes:
[#1379] Re: Yield — Andrew Hunt <andy@...>
>From: "Conrad Schneiker" <schneiker@jump.net>
[#1384] Re: Say Hi — mengx@...
My suggestion was to try to find a more comfortable method name (to me, and
[#1392] Re: Some Questions - Parameterised Types / Invariants — Andrew Hunt <andy@...>
>1. Parameterised Types / Template Classes
[#1398] Bignum aset — Andrew Hunt <Andy@...>
[#1488] Discussion happens on news.groups — Clemens Hintze <c.hintze@...>
Hi,
[#1508] Ruby/GTK and the mainloop — Ian Main <imain@...>
Hello Ian,
On Wed, Feb 23, 2000 at 02:56:10AM -0500, Yasushi Shoji wrote:
[#1516] Ruby: PLEASE use comp.lang.misc for all Ruby programming/technical questions/discussions!!!! — "Conrad Schneiker" <schneiker@...>
((FYI: This was sent to the Ruby mail list.))
From: "Conrad Schneiker" <schneiker@jump.net>
[#1528] ruby <=> python — Quinn Dunkan <quinn@...>
Hello! I'm new to ruby-talk, and mostly new to ruby. I'm making a document
[#1551] Ruby thread scheduling buglet — Ian Main <imain@...>
[#1569] Re: Ruby: constructors, new and initialise — Yukihiro Matsumoto <matz@...>
The following message is a courtesy copy of an article
[#1591] Certain char's not recognized by "." in regex? — Wes Nakamura <wknaka@...>
[#1592] Race condition in Singleton — Dave Thomas <Dave@...>
[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