From: Lyle Johnson <lyle@...>
Date: 2002-08-30T03:13:19+09:00
Subject: FXRuby Threading Problem Solved?

All,

I am hesistant to post this because I'm afraid it's just a dream ;)

A little history:

There's a long-standing bug related to using Ruby threads in a program 
that also uses FXRuby. This bug only shows up for the Visual C++ build 
(a.k.a. the "mswin32" build) of Ruby and FXRuby; threads seem to work 
just fine under Cygwin on Windows, and they definitely work fine under 
Linux. The problem is that shortly after the thread starts executing, 
the interpreter locks up. My debugging of the problem led to a point 
during thread scheduling (in the rb_thread_schedule() function) where 
Ruby attempts to switch contexts from one thread to another, using a C 
longjmp() call. The longjmp() should "jump" to a spot previously marked 
by some other thread using setjmp(), and pick up execution there, but in 
my case the code was "jump"-ing into oblivion.

One of the example programs distributed with FXRuby demonstrates the 
problem very well. The "groupbox.rb" example has some code that's 
currently commented-out; that code (if uncommented) would create a 
little thread that updates the clock in the lower right-hand corner of 
the example program's main window. This bit of code in groupbox.rb is 
commented-out precisely because it caused the Windows version to lock up.

I spent a lot of time tracking this down, as did Curt Hibbs (and perhaps 
others), but was never able to really identify what caused the lock-up. 
After a much-needed break, I decided to revisit the issue this morning. 
So I first checked out the latest CVS version of Ruby (now at 1.7.3) and 
built and installed that. Then I checked out FXRuby and built that 
against this Ruby. And then I tried to run the "groupbox.rb" example 
(after uncommenting the bit that creates a thread)... and it worked.

I haven't changed anything in FXRuby to "fix" this because, as far as I 
could tell, there was nothing to "fix". I can only assume that 
*something* has changed in Ruby 1.7 -- say, within the last month -- 
that made the problem go away. I'm scouring the ChangeLog to try to 
figure it out, because I'm awfully curious; I sure don't want anyone to 
"fix it back" ;)

Does anyone who's working on the core have an idea of why this has 
suddenly started working? And if so, is it something that can be easily 
back-ported to Ruby 1.6?

TIA,

Lyle