Re: [MACTCL] Potential problem with Tk state across fork()

[Daniel A. S. <st...@ma...>]

Sean,

On Friday, Mar 14, 2003, at 03:21 Australia/Sydney, Christopher Sean 
Morrison wrote:

> We've run into a rather interesting problem that has made itself 
> evident
> in the tcl/tk 8.4 release.  We have a piece of code that initializes a
> tcl interpreter, runs some commands (including loadtk), then fork()'s, 
> and
> generates the entire gui and enters the run-time loop.
>
> What effectively is "supposed" to happen is that the interpreter is
> created (fine), some commands are run including initializing our tk 
> state
> (fine), fork to detach from console (fine), finish initializing and
> present user interface (bad).
>
> Once we fork, something goes wrong (that we haven't pinned down) and 
> the
> windows fail to display.  What's interesting is that if we move the 
> fork()
> higher up and include the tk initialization, everything works just 
> fine..
>
> This would imply something is not being preserved across forks?

there is a well known issue on Mac OS X with code that links with any 
OS frameworks other than libSystem (and possibly CoreFoundation) having 
problems across forks. See for instance this week's darwin-developer or 
darwin-kernel list archive, this exact issue just came up.

The problem is essentially that all the higher level frameworks store 
references to Mach ports in order to do IPC (this may happen simply by 
linking with the framework, no code needs to be executed explicitly 
from your app), and that the child after the fork still has these same 
references but no longer access to the Mach ports (which are per 
process only). Much of the OS functionality relies on Mach ports, such 
as communication with the WindowServer, and all this will fail in 
interesting ways in the child as you've discovered...

I strongly suspect this is what bytes you; IIRC, the suggested 
workaround is to vfork() and execve() right away, not sure if that fits 
with your model though. (Note that vfork() can be up to 100 times (!) 
faster than fork() on OSX due to the specificities of the VM system, 
I've changed tcl's use of fork to vfork for that reason for 8.4.2)

So, I suspect that while code linking with Tcl.framework is fine across 
forks; code linking with and using Tk.framework is very unlikely to 
survive forks without exec (and if it does, it's still unsupported by 
Apple and may break in the future, or is broken in older OS versions, 
e.g. 10.1 is reportedly more sensitive than 10.2 in this respect).

> In either respect, I thought I'd mention it in case anyone has any 
> ideas
> or wanted to know about it.  Our problem was effecitvely solved by 
> moving
> up the fork, but that seems like it should be irrelevant or not 
> necessary.

I'm not even sure just moving the Tk initialization is guaranteed to 
continue to work in the future, just linking with Tk.framework will 
cause Carbon.framework (or X11 libs) to loaded and be initialized, 
which can cause references to Mach ports to be generated.

It's probably best to ask on the Darwin or Carbon lists for more 
details.

> We first noticed this on OS X, but have now found that this same 
> problem
> is evident on all platforms.  This sounds like something fundamental in
> the tk libs has changed.  I just can't imagine what.

it's strange that you'd see this on other platforms as well, this 
sounds too much like the mach port issue to be a coincidence IMHO...

Cheers,

Daniel

--
** Daniel A. Steffen     **  "And now for something completely
** Dept. of Mathematics  **   different"    Monty Python
** Macquarie University  **  <mailto:st...@ma...>
** NSW 2109 Australia    **  <http://www.maths.mq.edu.au/~steffen/>