async sub fire-and-forget
{
    do-stuff();
}
    
fire-and-forget(); #returns immedeatly, runs in parallel
[download]

Since I am stuck with 5.16 I tried another module, Async. It seems to work ok but there's one bit of behavior that I didn't expect (though I probably should have): if the parent script finishes, the subroutine fired by Async finishes as well (I was testing some writes after a sleep command). I guess this makes sense since the process is dying and thus everything on it's stack gets popped but I didn't comprehend this when I first started thinking about the problem.

I haven't yet tested it within the OpenSIPs module and don't know enough about how it works to wager a guess as to whether it keeps a persistent Perl env going while it operates (I know it spawns individual worker processes so each of them might have a unique env as well). Is it an unreasonable expectation to keep looking for a module that might be able to "fire-and-forget" a subroutine that can keep running even if the parent process dies?

In most cases, a parent process (or thread) should wait for its children to finish. In the case of processes, this (usually) cleans up zombies. In the case of threads, you have to wait until the threads are finished (or some reasonable time out) before ending the main, as this will also end the process containing all the threads.

It is possible for child processes to "detach" from their parent. I'm pretty sure that most of the fork manager type modules in CPAN will have an option for this.

Paraphrasing a fictitious soldier, "Fire-and-forget is fine as long as you never forget."

Thanks!

Unfortunately, I am stuck on 5.16 on RHEL

That doesn't work and I can't figure out from the docs how to get it to work.

use Future::AsyncAwait;

async sub _count {
    my $i;
    do { $i++ } until $i == 50_000_000;
    say "... counted";
}

say "Before";
_count();
say "After";


Output is:

Before
... counted
After
[download]

I tried this, which the buzzing in my head tells me should work, but no dice:

use Future::AsyncAwait;

async sub _add {
    my $one1 = await _count();
    my $one2 = await _count();
    return $one1 + $one2;
}

async sub _count {
    my $i;
    do { $i++ } until $i == 50_000_000;
    say "... counted";
    return 1;
}

say "Before";
my $f = _add();
say "After";
say $f->get;


Output:

Before
... counted
... counted
After
2
[download]

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.

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?

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]

My Async::Event::Interval may be of use here. It's exceptionally rudimentary in what it does.

This software is designed to run your async event at specific intervals (every number of seconds). Here is a very brief example:

use warnings;
use strict;

use Async::Event::Interval;

my $event = Async::Event::Interval->new(
    2,                  # number of seconds between execs
    \&callback,         # code reference, or anonymous sub
    'https://google.ca' # parameters to the callback
);

$event->start;

sleep 3; # your app does other stuff here

sub callback {
    my ($url) = @_;
    print "$url\n";
}
[download]

If you do only want it to run a single time, kill the proc after it does its work:

sub callback {
    my ($url) = @_;
    print "$url\n";
    kill 9, $$;
}
[download]

Then, if you want to spin it up manually later, just call $event->start again. If you need more arguments, append them in list form to the end of the new() call.

Using a thread for handling the Redis communication is probably the more efficient approach. In your case I would try with some module implementing a queue like Thread::Queue.

Another alternative would be to fork a slave process to work as a local buffer for the communication with Redis.