The problem is the order in which the handle's destructor and the END block are executed. If the file handle is destroyed first, you have a problem. When destroying a file handle, perl closes it, and closing a file handle opened with open '...|' causes perl to wait until the child process exits. Seeing as the kill command hasn't been executed, that won't happen.

You don't have that problem with open3 since you control when waitpid is called.

use IPC::Open3 qw( open3 );

my @tail_pids;

END {
   for my $tail_pid (@tail_pids) {
      kill TERM => $tail_pid;
      waitpid($tail_pid, 0);
   }
}

sub start_tail {
   my ($mw, $file) = @_;

   my ($from_tail, $tail_err);
   push @tail_pids, open3(undef, $from_tail, $tail_err, qw( tail -1lf 
+), $file);

   $mw->fileevent($from_tail, 'readable' => [ \&input_from_tail, $mw, 
+$file ]);
   $mw->fileevent($tail_err,  'readable' => [ \&sink,            $mw, 
+$file ]);
}
[download]

Notes:

• Placing END in start_tail won't work.
• You need a simple sink function that simply reads and discards the data waiting in the file handle.
• It now handles file names containing special characters.
• It doesn't handle SIGPIPE from tail ending prematurely.
• Untested.

The problem is the order in which the handle's destructor and the END block are executed. If the file handle is destroyed first, you have a problem. When destroying a file handle, perl closes it, and closing a file handle opened with open '...|' causes perl to wait until the child process exits. Seeing as the kill command hasn't been executed, that won't happen.

OK, I think I understand now.

The difference is that when you open the lexical, there's an (IO::Handle) object implicitly created. That object gets a call to DESTROY before the END block is called. The DESTROY method calls close, which has to wait for the subprocess to finish, which it never does.

In the case of a global file handle, Perl itself will close it after the END block is called. In that case, END can kill the process and everything else goes fine.

package Foo;
sub new { bless {} }
sub DESTROY { print "DESTROY()\n" }

package main;

my $foo = Foo->new();
print "I have a foo.\n";

END { print "END()\n" }

exit;
__END__
I have a foo.
DESTROY()
END()
[download]

Yup, that's exactly it. Even more interesting is the difference between lex and pkg vars:

{  package Pkg;
   sub new     { my ($class, $text) = @_;
                 return bless(\$text, $class); }
   sub DESTROY { my ($self) = @_;
                 print "DESTROY $$self\n"; }
}

my  $lex = Pkg->new('file scope lex var');
our $pkg = Pkg->new('pkg var');
END { print "END\n" }
print("At end of script\n");
[download]

At end of script
DESTROY file scope lex var
END
DESTROY pkg var
[download]

I don't know if the order is unchanging. I wouldn't count on it. Doing our $pkg2 = \$lex; or sub test { $lex } would change the order, for example.

That's okay if your program already has an asynchronous event loop (Tk) running. It gets messy if you have to do it yourself.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Check the original post. He is, which is also the reason he can't use File::Tail.

Simple answer: I don't know. Maybe if you placed the open in a bare block so that the lexical handle gets closed automaticially?