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 res
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
2009/10/13 Andrew Feren
> I'm not really sure, but I'd guess that the Daemon module isn't
> copying/cloning something that it should. As a result
> Win32::Daemon::StopService(); is getting called unexpectedly in a DESTROY or
> END block when the child exits.
>
That is probably the reason as th
I took some time at lunch today and got Win32::Daemon functional on my
system. I've attached a slightly hacked up version of your original
script that "works" with fork(). I would, however, suggest that
Olivier Mengué's work around described earlier in this thread is saner
than what I have d
Hi,
Andrew Feren wrote:
> Andreas Altergott wrote:
> Did you try the suggested change?
Yes, I did. It did not work for me.
> I tried very briefly to get Win32::Daemon working, but it didn't want to
> work for me, so I can't speak to Win32::Daemon issues. That said your
> original service is ex
Hi,
Olivier Mengué wrote:
> 2009/10/9 Andreas Altergott
>> 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() me
Andreas Altergott wrote:
Hi,
Andrew Feren wrote:
Something like the following will give you better results.
my $pid;
if($pid = fork()) {
print(FOUT "running ($pid)\n");
wait();
} else {
open(FOR, '>>', 'C:\delme-kid.txt');
thread();
In my experience Perl on Windows does not handle the (Program => \&foo)
case well at all. I have had better luck with the (Program => sub {
foo() }) case, but even that seems a bit iffy to me.
I'm still waiting for someone who can explain why sub{ foo() } sometimes
works when \&foo doesn't.
The question in my mind: If fork() is so troublesome on Windows, do we
have an alternative?
For the (Program => "foo.exe") form, we can possibly avoid fork()
altogether. http://rt.cpan.org/Public/Bug/Display.html?id=48715#txn-659406
includes some code that promises to work well.
For the
2009/10/9 Andreas Altergott
> Hi,
>
Hi Andreas
> this will be especially interesting for dolman :-)
>
dolmen !
> as already described in previous emails there is a big problem when
> using POE::Wheel::Run::Win32 with Win32::Daemon as a windows service.
> Your service will get a termination
Hi,
Andrew Feren wrote:
> Something like the following will give you better results.
>
>my $pid;
>if($pid = fork()) {
> print(FOUT "running ($pid)\n");
> wait();
>} else {
> open(FOR, '>>', 'C:\delme-kid.txt');
> thread();
> clo
While I have several unresolved issues with fork on Windows I think they
biggest problem with your script is that the fork logic backwards.
Something like the following will give you better results.
my $pid;
if($pid = fork()) {
print(FOUT "running ($pid)\n");
wai
Hi,
this will be especially interesting for dolman :-)
as already described in previous emails there is a big problem when
using POE::Wheel::Run::Win32 with Win32::Daemon as a windows service.
Your service will get a termination request from windows, as soon as any
child process terminates.
This
13 matches
Mail list logo