Hi, Olivier Mengué wrote: > 2009/10/9 Andreas Altergott <alterg...@mira-consulting.net> >> 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
signature.asc
Description: OpenPGP digital signature
