Object:...rpreter(3)

💅 NAME 💅

ok so bestie, this is Object::Remote::Role::Connector::PerlInterpreter — a role for connections to a Perl interpreter. that's the whole vibe. it's from the User Contributed Perl Documentation section (section 3, perl land, you know the one). 🎀

---

✨ SYNOPSIS ✨

like, here's the whole mood in code:

use Object::Remote;

my %opts = (
  perl_command => [qw(nice -n 10 perl -)],
  watchdog_timeout => 120, stderr => \*STDERR,
);

my $local_connection = Object::Remote->connect('-', %opts);
my $hostname = Sys::Hostname->can::on($remote, 'hostname');

no cap, that's it. that's the flex. 🦋

---

🌸 DESCRIPTION 🌸

so this right here is the role that makes connections to a Perl interpreter that's running in a different process possible. main character behavior fr fr.

the new Perl interpreter can chill on the local machine or a remote one — your call — and you configure it via the arguments you pass to the constructor. iconic. 👑

---

🫶 ARGUMENTS 🫶

• perl_command — by default the Perl interpreter runs as perl -, but you can totally change that: just hand over an array reference as the value to the perl_command attribute while you're constructing. easy. 💅
• stderr — okay so if this value is defined, it gets used as the file handle that receives STDERR output from the Perl interpreter process, and the I/O gets performed by the run loop in a non-blocking way. but if the value is undefined, then the remote process's STDERR connects directly to the local process's STDERR, without the run loop managing the I/O at all. the default value is undefined. 🍓

so there's a few ways to use this feature, and honestly there's lore:

• by default, the behavior is to form one unified STDERR across all the Perl interpreters — including the local one. for small scale, quick operation, this is a predictable and easy way to get at error messages generated anywhere. and if the local Perl interpreter crashes, the remote Perl interpreters still have an active STDERR, so it's still possible to receive output from them. generally a good thing! but it can cause issues. 😭
• when you use a file handle as the output for STDERR, once the local Perl interpreter is no longer running there's no longer a valid STDERR for the remote interpreters to send data to. meaning: it's no longer possible to receive error output from the remote interpreters, and the shell will start to kill off the child processes. 💀
• passing a reference to STDERR for the local interpreter (like the SYNOPSIS shows, bestie, look up 👆) causes the run loop to manage I/O — one unified STDERR for all Perl interpreters that ends as soon as the local interpreter process does — and the shell will start killing children when the local interpreter exits.
• it's also possible to pass in a file handle that's been opened for writing. this would be useful for logging the output of the remote interpreter directly into a dedicated file. logging slay. 📝

• watchdog_timeout — if this value is defined, it's used as the number of seconds the watchdog will wait for an update before it terminates the Perl interpreter process. the default value is undefined, which means no watchdog. see "Object::Remote::Watchdog" for more info. 🐕

lowkey important: the stderr behavior differences above are real behavior differences, not just vibes. pick deliberately. 🙈

---

👀 SEE ALSO 👀

• "Object::Remote" — go look, iykyk ✨

---

and that's the whole page, bestie! 🎀 written under perl v5.40.2, dated 2026-07-16 — so if you're reading this way later, hi from the past, hope your STDERR is unified and your watchdogs are chill 💜