Hi,
I have noticed a little strangeness, a mere ‘require “tkscrollbox”’
before a fork will cause weird effects even if all Tk
objects are created after the fork. Eg exiting the process
which created the Tk objects doesn´t destroy them and using explicit
$top.withdraw sometimes causes even X server hickup.
Doing the “require” after the fork leads to correct behaviour,
this is ruby-1.6.7 on Redhat 8.0. Is it a known problem?
I have attached the small testprog that demonstrates the
trouble.
Richard
forktest (595 Bytes)
Hi,
From: Richard Zidlicky rz@linux-m68k.org
Subject: fork and Tk problem
Date: Thu, 12 Jun 2003 00:57:58 +0900
Message-ID: 20030611144839.GA5228@linux-m68k.org
I have noticed a little strangeness, a mere ‘require “tkscrollbox”’
before a fork will cause weird effects even if all Tk
objects are created after the fork. Eg exiting the process
which created the Tk objects doesn´t destroy them and using explicit
$top.withdraw sometimes causes even X server hickup.
Yes. A Tk interpreter can NOT be shared by two processes.
this is the obvious part.
You shold call ‘require “tk”’ AFTER call fork.
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.
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.
Richard
···
On Thu, Jun 12, 2003 at 04:20:35PM +0900, Hidetoshi NAGAI wrote:
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?
···
From: Richard Zidlicky rz@linux-m68k.org
Subject: Re: fork and Tk problem
Date: Sat, 14 Jun 2003 05:11:58 +0900
Hidetoshi Nagai (nagai@ai.kyutech.ac.jp)
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?
sure.
If change tk.rb to create a interpreter manually,
you will success to fork after “require ‘tk’”.
my idea was to postpone the creation of the interpreter
untill the program attempts to create the first Tk
widget - would cause less surprise for people who are
used to group their "require"s on top of each file and
afaics remain compatible with current apps.
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?
The alternate methods look ok… otoh beeing completely unable
to use fork is a limitation.
Isn´t there some Tk.kill_interpreter or similar method that
could be used to kill the duplicate interpreter after fork?
Perhaps simply closing the X connection would be sufficient
although not the cleanset solution.
Richard
···
On Sat, Jun 14, 2003 at 12:44:11PM +0900, Hidetoshi NAGAI wrote: