Re: Advice: Async Options for fire-and-forget subroutine

If you don't even care about return values, why not just use fork. You might need to be careful not to accidentally forkbomb yourself. Look at something like Parallel::ForkManager to throttle the forking if you want more control or your jobs might come in overwhelming numbers.

Comment on Re: Advice: Async Options for fire-and-forget subroutine

Replies are listed 'Best First'.
Re^2: Advice: Async Options for fire-and-forget subroutine by mwb613 (Beadle) on Oct 21, 2017 at 23:13 UTC
Thanks Mom! If I were a dumb person who'd never run any sort of forking before, should I just use fork? I also see forks, perlfork, many modules including the one you listed in your post. It sounds like, based on some of the things I'm reading, that my use case -- firing and forgetting -- will create zombies which I do not want considering it will be part of a long running process. Also, just to clarify, the pid returned by fork() is the system PID (I'm running RHEL) or a Perl specific PID? If the former I could potentially stash the PIDs and kill them from a whole other process, no?	[reply]
Re^3: Advice: Async Options for fire-and-forget subroutine by Your Mother (Archbishop) on Oct 23, 2017 at 13:26 UTC
Untested simplistic pseudocode that ignores a potential error point (`0 == fork()` is for the child side of the `fork` and it's not tested here). Forked processes are regular processes on *nix, just children of the original program. `$SIG{CHLD} = "IGNORE"; while ( program_should_be_running() ) { # Might want a sleep or a usleep (from Time::HiRes) here. if ( my $pid = fork ) { # Do nothing...? This is the "permanent" parent process. # $pid is the child $$ } else { run_your_sub(); # Processes could stack up fast. } }` [download]	[reply] [d/l] [select]