From: Richard Zidlicky <rz / linux-m68k.org>
Subject: Re: fork and Tk problem
Date: Sat, 14 Jun 2003 05:11:58 +0900
Message-ID: <20030613111911.GA1066 / linux-m68k.org>
> this is what got me. Although I am aware that "require" may
> do pretty much anything I would have thought the Tk interpreter
> or X connection would be created only when I explicitly create
> a widget, not by merely require'ing Tk.

Yes. Current tk.rb create a Tk interpreter object automatically. 
You cannot create and control widgets without a Tk interpreter.
Usually it has no problem, doesn't it? 
If change tk.rb to create a interpreter manually, 
you will success to fork after "require 'tk'".
Then, each process has its own Tk interpreter. 
Of cource, a Tk interpreter cannot treat widgets on other 
Tk interpreter without Tcl/Tk's send command (See Tk.appsend, 
Tk.rb_appsend, and so on).
It is same to do "require 'tk'" on each process after fork. 
Therefore, I think there is no reason to change tk.rb. 

> Not a problem in app, however I figure a clean way to destroy
> the Tk objects in a forked process would be nice in many
> circumstances. The same of course holds for the other
> GUI Toolkits.

Probably, I can understand what you want. 
But, unfortunately, a Tcl/Tk interpreter doesn't support fork.  
I think so, because there is no fork command on Tcl/Tk.
Ruby/Tk calls and controlls Tcl/Tk interpreter directly
(NOT inter process communication). So, if Tcl/Tk cannot supprt 
some functions, Ruby/Tk cannot suppot almost all of them. 
And if some Tcl/Tk extend libraries are loaded on Tcl/Tk, 
Ruby/Tk can use the functions of such libraries (see TkPackage module).
It may be possible by wrapping fork method;  
for example, create a pipe, override Tk.tk_call method to send 
message by the pipe, create thread to do inter process communication, 
and create a function to erace Tcl/Tk interpreter from memory without 
destroy widgets (I have no idea how to create such function). 
# Or use druby. :-) At least, we'll have to use IPC. 
It is so heavy. And if have to use IPC, probably there are better ways 
than such heavy way. 
Don't you think so? 
-- 
                                  Hidetoshi Nagai (nagai / ai.kyutech.ac.jp)