How to portably stop processes?

[haj]

Hello Monks,

I am looking for a "clean" way to terminate processes I've created on both Linux and Windows.

The processes exec an external program which in some situations intentionally runs "forever", or until stopped by someone else.

On Linux, this is straightforward: $child_pid = fork, then in the child process exec. Later, kill 1, $child_pid from the parent process.

On Windows (Windows 11 in my case), fork and exec are emulated but work quite fine... only that I don't know how to kill the subprocess. The PID returned from fork is apparently useless. When I kill 1 $child_pid, the main process complains Terminating on signal SIGHUP(1) and terminates immediately, leaving the external process running like a zombie. I can get rid of the zombie by entering Ctrl-C on the command line.

On Windows - and only on Windows - I can replace fork, exec and kill by the corresponding functions from Win32::Process. If I just use Win32::Process, then this would be a dependency also on Linux, which is unwanted, so I'd go for a solution with if, and write two separate helper modules.

Has this exercise already been done? I didn't find anything under Process...

[NERDVANA]

Actually fork and exec don't "work fine" on Windows :-( They're cheap approximations that have all sorts of bad consequences for programs written in a Unix mindset. You can read about it on Proc::Background::Win32

That module is also my recommendation for how to handle your problem. (disclaimer: I'm the maintainer) (and bah, there's a POD bug on that page. I'll get that fixed...)

Oh, but if you use cygwin perl, fork and exec work fine and do create new processes.

[haj]

Actually fork and exec don't "work fine" on Windows :-(

Fair enough: I should have been more specific. They were good enough for my particular problem ... until I wanted to have "infinite" processes.

And indeed, Proc::Background is pretty much exactly what I was hoping for. Thanks a lot!

[LanX]

> > > If I just use Win32::Process, then this would be a dependency also on Linux, which is unwanted

> And indeed, Proc::Background is pretty much exactly what I was hoping for. Thanks a lot!

Well ... Proc::Background relies on Win32::Process

package Proc::Background::Win32;
$Proc::Background::Win32::VERSION = '1.30';
# ABSTRACT: Windows-specific implementation of process create/wait/kil
+l

...

use Win32::Process qw( NORMAL_PRIORITY_CLASS INFINITE );   # <---

...

update

and that's how it's avoided as dependency on Linux

https://metacpan.org/release/NERDVANA/Proc-Background-1.30/source/dist.ini

[OSPrereqs / MSWin32]
Win32::Process = 0.04
Win32::ShellQuote = 0.003001

[eyepopslikeamosquito]

In case it's of use, I wrote a couple of scripts years ago to run an external command on both Unix and Windows, killing it if it took more than a specified timeout, and reporting how long it took to run:

• Timing and timing out Unix commands (using fork, exec, kill, waitpid)
• Timing Windows commands (first attempt using Win32::Process)
• Re: Timing Windows commands (improved version using Win32::Job)

I enjoyed using Win32::Job much more that Win32::Process. BTW, I never use fork/exec emulation on Windows, too much general weirdness and confusion between threads and processes for my tastes.

Related Win32 Modules by Jan Dubois

• Win32::Process
• Win32::Job
• Win32::File
• Win32::Console
• Win32::Pipe
• Win32::Registry
• Win32

Other Handy Win32 Modules

• Win32::LongPath by Robert Boisvert - mentioned by ikegami in Re^3: how are ARGV and filename strings represented?

See Also

• Re^3: Parallel::ForkManager install fails (Apr 2024)
• how to system call that exits by ObiPanda (Apr 2024)
• exec() fails with strange message by dissident (May 2024)

Updated: Added See Also and Related Win32 Modules by Jan Dubois sections

[LanX]

I'm no expert, but fork and perlfork talk at length about not to use kill on children when fork was emulated.

See https://perldoc.perl.org/perlfork#kill()

There are various alternatives listed in perlipc though.

An SSCCE with tests might help provide alternatives.

> If I just use Win32::Process, then this would be a dependency also on Linux

I'm quite sure that you can have install dependencies based on the actual OS. Never tried this tho.

HTH. :)