Hi, 

From: Ferenc Engard <ferenc / engard.hu>
Subject: Re: 2 questions about TkVariable and ruby/tk
Date: Mon, 8 Sep 2003 08:57:01 +0900
Message-ID: <3F5BC55D.E1FA0C96 / engard.hu>
> > > It prints out 'before mainloop', but do not creates its X form, and
> > > cannot be interrupted by ctrl-c. Tested with 1.6.8 and 1.8.0. (Anyway,
> > > TkVariable::result generates a (catched) error when the tcl variable is
> > > an array, that's why the program in my previous posting encountered this
> > > problem.)
> > 
> > Sorry. It is a bug on tcltklib.c. I fixed it on CVS.
> 
> Why does it work in the win32 version 1.6.8? :-O  

There are important changes from 1.6.8 to 1.8.0. Those are 
 (1) fixed the problem of eating 100% CPU power, 
 (2) support multiple Tk interpreters.
'seem to ignore KILL signal' problem depends on the 1st one, 
and 'return no exceptions' problem depends on the 2nd one. 

To get better response for Ruby/Tk with other Ruby threads and fix
some problems (sometimes hung up when controling widgets from threads
except the eventloop thread), I re-wrote the eventloop implementation
on tcltklib.c. But that had the 100% CPU problem. 
Although the problem was fixed on 1.8.0, then I forgot to check 
signal traps when the eventloop thread is the only thread. 

If we want to run a safe-Tk interpreter, we must control at least 
two interpreters; those are the master IP and the slave safe-Tk IP. 
All interpreters running at same time are handled by only one eventloop. 
If the eventloop accepts an exception from one interpreter and stops
working because of the exception, other interpreters stop working too. 
That is meaning that one interpreter can stop other interpreters. 
Of course, it is undesirable. I changed tcltklib.c on 1.8.0 release to
avoid the problem. But some bugs lay on the changes.

I think (or I want :-)) those were fixed by the last change of
tcltklib.c on CVS. Whenever you find problems that are not fixed, 
please report them on the ML. Whatever problems you found are welcome.

# If you are interested in implementation for selecting the proper Tk 
# interpreter on a same method call (e.g. TkButton.new), please see 
# multi-tk.rb.
-- 
                                  Hidetoshi NAGAI (nagai / ai.kyutech.ac.jp)