Re: fork, tk, win32

The problem your experiencing is caused by the fact that Tk's just enough aware of threads to compile, and Win32's fork uses threads, and not truly seperate processes like UNIX. When your application exits, Tk's destruction routines get called. Apparently Tk gets confused with multiple threads, and that causes your problem.

The easiest solution to this problem is to move your Tk stuff to after the code for the child in your program. That is after the if. That should prevent Tk needing to call the destruction routines in the child.

Update: To be more specific, the problem is caused by a Widget (MainWindow) being in exsitence for the child when it exits. A look at the tk source code indicates that the use Tk does not appear to be a problem.

Comment on Re: fork, tk, win32 Select or Download Code

Replies are listed 'Best First'.
Re: Re: fork, tk, win32 by Eradicatore (Monk) on Jun 03, 2001 at 19:08 UTC
Thanks! That's the most info I've gotten in a while. I really appreciate it. You're totally right about putting the mainwindow after the if. I even just added a button and all is fine. I wonder though if this will help me in my final app. I will need to have a gui created, and then when they click "update" I want to go get a web page using fork, and use the results to show new stats on the gui basically. Can I just put the fork in a subroutine above the definition of the GUI? I guess I don't know enough to know if that would make a difference. If not, any thoughts on how to make that work? Thanks again!!! Justin	[reply]
Re: Re: Re: fork, tk, win32 by wog (Curate) on Jun 03, 2001 at 19:38 UTC
With Tk, you probably want to look at the documentation for Tk::fileevent. One solution is to use the pipe or socketpair function to generate streams from your parent to your child and vice-versa. (perlipc gives an example of this under the heading Bidrectional Communication with Yourself.) The idea would be is that your child could act as a server, recieving notification from the parent when an update is needed. Then it could send the information back to the parent which could know its there from Tk::fileevent. (so the parent could do it within the Tk event loop.)	[reply]