For timing out a spawned child see alarm and the working example in there.

For reading back the output of the child, why not make child write its output to a specified file, via a command line parameter, e.g. `child.exe -o out.123`, or `child.exe > out.123`. 123 could be child's pid. Problem with incomplete output if you timeout child, so add a marker at EOF indicating successful completion of process.

But you need to keep track of how many children are currently running because you don't want to overwhelm your system. And that additional requirement leads us to a thread-pool where children splash. This example by BrowserUK is a classic in my books: How to create thread pool of ithreads

1min addition: Sharing data between threads is possible but somewhat tedious, you want to keep it to a minimum (I don't like data duplicating), e.g. notifying of children pids. It is possible and easy to communicated via shared variables, integers, strings etc. but moving to shared deep data structures or objects is something you don't want because even if it is possible (I don't know) you can do without the overhead.

bw, bliako

But alarm sends a signal to the process that called alarm, not the child process, right? Even if it sent it to the child, the child process would need a signal handler for that process.

Maybe I wasn't clear enough in my question. The child process is not a single script, but can be a variety of scripts, and may not even be Perl. I don't want to require the child scripts be modified. Well, that was the approach I was pushing for, but my question was pertaining to changing only the parent script. How can a threaded Perl script run any system command, capture that command's output, and kill it if it runs for too long?

But alarm sends a signal to the process that called alarm, not the child process, right?

Unless the process that called alarm is the process that created child, and by killing the process you kill the child. Try alternating 5 and 2 in the script I have whipped up below (make sure you read the warning, if file xyz is written then child has terminated OK, if not it was timed out):

#!/usr/bin/env perl

# for https://perlmonks.org/?node_id=1231710
# author: bliako
# 27/03/2019
# WARNING: it writes and deletes file 'xyz' in local dir

use strict;
use warnings;

sub spawner {
    my ($cmd, $timeout) = @_;
    print "spawner starting.\n";
    my $pid = fork();
    if( ! $pid ){
        print "spawner in child.\n";
        eval {
            local $SIG{ALRM} = sub { die "alarm blah blah" };
            alarm $timeout;
            print "starting system command.\n";
            `$cmd`;
            print "system command ended.\n";
            alarm 0;
        };
        if( $@ =~ /^alarm blah blah/ ){ die "spawner: child timed out"
+ }
        elsif( $@ ){ die "spawner: something wrong with eval block whi
+ch spawns '$cmd'" }
        exit 0;
    }
    print "spawner ending.\n";
}

spawner('rm -f xyz; sleep 5; touch xyz', 2);

wait();

if( -e 'xyz' ){ print "command seems to have terminated on its own wil
+l.\n"; }
else { print "command has timed out.\n"; }
[download]

bw, bliako

"But alarm sends a signal to the process that called alarm, not the child process, right? Even if it sent it to the child, the child process would need a signal handler for that process."

Although I've caused all manner of consternation with doing process stuff with Windows (including killing off sub-procs), I've found that Perl is weird when talking processes/threads with that OS. "Processes", I've managed (mostly, but with difficulty), but threads, I'd definitely need advice from our experts.

Perhaps you could lay out at least some pseudo-code (or minimal working/broken problematic example) of what you've got, so the experts can see if they can help sort out a solution?