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

Hi,

Olivier Mengué wrote:
> 2009/10/9 Andreas Altergott <[email protected]>
>> this will be especially interesting for dolman :-)
> 
> dolmen !

Sorry for the confusion.

>> This happens because POE::Wheel::Run::Win32 is using the fork() method.
> 
>  I do not know how exactly ActiveStates Perl handles the fork() method,
>> but it does it different than the system() method.  The system() method
>> also creates a child process, but it waits for the child until it
>> terminates.  This does not initiate a termination request to the
>> service.  Although both do create sub processes.
>>
>> Speaking in windows terminology one has to say threads instead of
>> processes.  So system() is using fork() according to the perldocs.  And
>> fork() tries to do a real fork() if it is available.  On windows it is
>> not.  So it has to create a thread.  I don't know how it does terminate
>> a thread though.  It must be different when you use system(), else it
>> wouldn't terminate your service.
>>
>>
> This description is incomplete.
> POE::Wheel::Run{,::Win32} on Win32 creates an external process using
> Win32::Job and uses the thead created with fork() to monitor the job
> (->watch) and report its status.

Maybe I get it wrong, but doesn't POE::Wheel::Run::Win32 create a fork
in line 277.  The child then does what you explained.

>> Luckily, using threads is not a blocking process.  It means that your
>> POE program can continue working, while the thread is also doing it's
>> work.  The only drawback is, that your programs will be windows
>> specific.  You can not do a 'use threads;' inside of eval, require or
>> any other trick to make it system independent.
>>
>>  o http://perldoc.perl.org/threads.html
>>
>> The fast solution is to use threads instead of POE::Wheel::Run::Win32.
>>
> 
> I think that POE::Wheel::Run{,::Win32} already does this.

As already said, I don't see it using threads anywhere.  I mean "use
threads" not simply fork.

>> I've been reading in some previous mails, that POE::Wheel::Run and
>> POE::Wheel::Run::Win32 have been merged.  This is nice to hear :-)
>> But in this case it complicates things.  Because now POE::Wheel::Run is
>> system independent by using fork().
> 
> 
> If you look at the code you'll see that the code path on Win32 is quite
> different.
> So "merged" does not means "does the same".
> 
> Also, the aim of the merge is to make your code system independent (of
> course this is not the case when using Win32::Daemon too).
> 
>  As described this is not possible

Yes, it'd be beautiful, to have system independent code and an open
source alternative to Win32::Daemon.

> I think that the problem is in Win32::Daemon, for which we don't have the
> source (his author, Dave Roth seems to have disappeared without publishing
> the source for its latest binary release). See the bug where I have posted a
> simple test case that does not involves neither POE,
> POE::Wheel::Run{,::Win32}, Win32::Job or POE::Component::Daemon::Win32.

Did you try the attached code in the initial email?  It does not depend
on POE or Win32::Job either, but it did work for me.

> I managed to workarounk the bug by separating the program in two process:
> - a service wrapper that uses Win32::Daemon, open a server socket and
> launches the real service as a subprocess. When it receive a command from
> the service manager it forward it to the child as a message on the socket.
> - the real service : connects to the service wrapper socket when it starts
> and monitors it with a POE::Component::Client::TCP
> I wanted to use Win32 pipes instead of Internet sockets, but I've found
> nothing to monitor them with POE (there is no select() on file/pipe handles
> in the Win32 world).
> Anyway this works because there is exactly only one process launched from
> the wrapper, and when the child exits, we want the service to stop which
> matches the state change that Win32::Daemon sends.
> However this is a really ugly and we will still need one day a fixed
> Win32::Daemon.

I completely agree with you that there is a need for a replacement of
Win32::Daemon, but I am not so sure if this actually is a bug in
Win32::Daemon.  I just don't know.


Regards,
Andreas

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrTm/AACgkQImDrLy4cAN+YnwCfXHKJ7RPFbtEQuwzOYPen2ooI
tn8An2qKNktT3xdUwio2gdZc/GEnDxPV
=ESvr
-----END PGP SIGNATURE-----