Re: POE::Wheel::Run::Win32 and Win32::Daemon

Andreas Altergott wrote:
> Hi,
>
> Andrew Feren wrote:
>   
>> I removed the calls to exit() and the service started working as
>> expected.  Calling exit() from the child resulting from perl's pseudo
>> fork is supposed to work (and often does).  Unfortunately it has been my
>> experience that sometimes the results are a catastrophic  failure.
>>     
>
> That's a surprise.  So the exit subroutine must call something
> different, than simply letting the program run out.  That would be a
> nice question to the ActiveState developers.
>   
This is an area that has always bothered me.

The "perlfork" docs state :

    /exit()/ always exits just the executing pseudo-process, after
    automatically /wait()/-ing for any outstanding child
    pseudo-processes. Note that this means that the process as a whole
    will not exit unless all running pseudo-processes have exited.

This makes sense since the goal, as I understand it, is to as much as 
possible have fork() code just work on Windows.  For many examples it does.

Perl threads started life as a way to implement "perlfork".  OK, so far 
so good.  However, if we read the "threads" documentation we find :

    *exit(status)*

    Calling exit EXPR <http://perldoc.perl.org/functions/exit.html>
    inside a thread causes the whole application to terminate. Because
    of this, the use of |exit()| inside threaded code, or in modules
    that might be used in threaded applications, is strongly discouraged.

    If |exit()| really is needed, then consider using the following:

       1. threads->exit() if threads->can('exit'); # Thread friendly
       2. exit(status);

Clearly pseudo-processes (aka threads ;) are intended to do the right 
thing relative to exit (and with good reason).  However, the foundation 
they are built on is very exit() averse.
> There is the possibility to use fork() as long as you do not use exit()
> then.  Probably that's why threads have been working.  I did not use
> exit() there.
>   
You *really* don't want to call exit() if you are using threads directly.
> I'm just curious.  Is there another way to stop a POE application
> immediately?
>   
The answer depends a little on your intent.  If you really want to 
terminate an application inclusive all threads exit() works great (as 
long as you don't need to do any cleanup ;).  If you just want to 
terminate a single thread try threads->exit() (if it is available). 

After tripping over problems with exit() a couple times I just take care 
to have a code path that will quietly run out of things to do without 
calling exit() explicitly. 
> There's the possibility of using stop().  If I run this inside the
> forked child, this should not affect the parent.  But still some code in
> the _stop state will get executed.
>
>   
>> How did you use exec()?  calling exec() after the fork() failed for me
>> in the same way as calling exit.
>>     
>
> I did not try to run exec() from a fork.  That's sad to hear, else one
> could use Wheel::Run by setting the program to an array.  This would run
> exec() on line 443, instead of the final exit() on line 440 in Wheel::Run.
yep.  That was what I thought too, but no luck.

IMO death by exit() in a pseudo-process is a bug, but it isn't clear if 
the bug is in the "perlfork" implementation my code or some 
combination.  I did notice that Win32::Daemon starts several threads.  
 From the outside looking in I can't tell if they are pseudo-processes 
or threads, but I'd guess they are threads.  Which brings me to this 
quote from the perl thread tutorial.

    "Thinking of mixing |fork()| and threads? Please lie down and wait
    until the feeling passes."

I think, from the rest of the context, that this quote is referring to a 
real UNIX fork() and not "perlfork", but then again...

I wonder if calling exit from a pseudo-process would kill off threads 
that happen to be running and aren't also pseudo processes.

-Andrew