Quoting Rocco Caputo ([EMAIL PROTECTED]):
> How's that going? I've been tracking the problem down on and off
> today, but no luck. Some notes:
>
> 1. The exit() in POE::Wheel::Run doesn't bypass "forked" object
> destruction. With ASSERT_DEFAULT on (the default for POE's tests), a
> lot of "this thing leaked" messages show up. They're harmless, more
> or less, but object destructors are still being called in the "child"
> process.
>
We've discussed that quite extensively and it seems the right thing to
do. Looking at the code:
unless (POE::Kernel::RUNNING_IN_HELL) {
eval { POSIX::_exit(0); };
eval { kill KILL => $$; };
eval { exec("$^X -e 0"); };
};
exit(0);
We don't want to do the first eval because _exit will kill all threads.
Fork on windows is implemented by starting a new thread with a cloned
interpreter. Kill will work, as it will kill a thread outright. But the
docs have dire warnings against its usage:
kill() kill() can be used to terminate a pseudo-process by
passing it the ID returned by fork(). This should
not be used except under dire circumstances, because
the operating system may not guarantee integrity of
the process resources when a running thread is
terminated. Note that using kill() on a
pseudo-process() may typically cause memory leaks,
because the thread that implements the pseudo-
process does not get a chance to clean up its
resources.
So that is not a good choice. The third eval is not useful on Windows,
as it will do a CreateProcess, which is slow, and then immediately
exit. Better then to do a normal exit.
The destructors are indeed called, maybe this should just be documented,
that you need to take care in your DESTROY.
> Is there any way to exit from the child "process" without triggering
> all the object destructors that were forked into it?
>
Not that I know of. Which doesn't mean much :-) Should ask Gurusamy.
> 2. The {STDIN,STDOUT,STDERR}_FILENO checks are probably important. If
> you notice just below the comment "Close any close-on-exec file
> descriptors.", files with high descriptor numbers are closed. Maybe
> the explicit checks can be removed if the loop is changed to ignore
> fileno(STDIN), fileno(STDOUT) and fileno(STDERR) rather than mimic
> UNIX's close-on-exec behavior.
>
That makes sense. The loop should close all but the fileno ones.
> 3. tests/30_loops/50_tk/wheel_run.t passes its tests when run
> stand-alone. To re-create the failure deterministically, add this
> code to test.pl just before runtests() is called:
>
> @test_files = grep /50/, @test_files;
> while (@test_files) {
> last if $test_files[-1] =~ /50.*tail/;
> pop @test_files;
> }
>
I only now realize that you are seeing this with Tk. So the normal
wheel_run.t passes? Good. For me the Tk test hangs. I will investigate.
I'm using Tk 804.027. Which one come with ActiveState.
Regards,
--
Merijn Broeren | She doesn't want you to understand her. She knows that's
Software Geek | impossible. She just wants you to understand yourself,
| everything else is negotiable.
