Thanks, this patch has been applied and will be part of the next CPAN
release in 1-3 days.
- R.
[ilya@iponweb.net - Wed Jan 14 09:52:18 2004]:
> >>>>> "BSvR" == Barrie Slaymaker via RT <comment-IPC-Run@rt.cpan.org>
> writes:
>
>
> BSvR> On Wed, Jan 14, 2004 at 08:46:45AM -0500, Guest via RT wrote:
> >>
> >> As I understand from select man page "Interrupted system call"
> (EINTR) is a normal condition and it is not correct to croak or die
> on it. Instead of croacking IPC::Run should repeat (?) select. As a
> quick workaround I just commented out this line.
>
> BSvR> You *might* want to uncomment it and add another term to the if
> BSvR> expression that only disables it in that case.
>
> BSvR> I'm in patches-only mode on most of my modules as my business is
> quite
> BSvR> busy these days. There's also an open issue (see the TODO test
> in the
> BSvR> test suite) dealing with moving large amounts of data.
>
> Ok. Here a patch
>
> --- lib/IPC/Run.pm.bak Wed Jan 14 17:43:07 2004
> +++ lib/IPC/Run.pm Wed Jan 14 17:44:00 2004
> @@ -3118,7 +3118,7 @@
> }
> last if ! $nfound && $self->{non_blocking} ;
>
> - croak "$! in select" if $nfound < 0 ;
> + croak "$! in select" if $nfound < 0 and $! != POSIX::EINTR;
> if ( _debugging_details ) {
> my $map = join(
> '',
>
> Seems to work for me. As I understand from source code select() is
> already in loop so there is no need to redo it right after recieving
> EINTR. select() will be repeated eventually anyway.
>
> BSvR> If you're just using the run() call, you might want to test
> drive
> BSvR> IPC::Run3 instead. It uses temp files instead of pipes (and on
> Win32
> BSvR> instead of pipes *and* sockets combined, ugh).
>
> Last time I checked I needed more that IPC::Run3 provides so probably
> it is not an option for me.
>
> >> P.S. Sorry, no test case. It is not clear for me how to trigger
> this
> >> in small test case. In fact I cannot even reproduce this problem
> with
> >> my application if I step through it in debugger.
>
> BSvR> It might be that, when not in the debugger, the parent process
> is
> BSvR> getting a signal (I'm assuming Unix-like or at least POSIX-like
> BSvR> environment here) and IPC::Run needs to repeat. Perhaps that
> approach
> BSvR> could be taken to make a valid test case: have a child send a
> signal to
> BSvR> the parent. I'd like to at least capture this as a todo test so
> I never
> BSvR> forget it's there.
>
> This test case seems to be a bit not trivial (compared with patch) and
> I'm in "patches-only mode on most of my modules as my business is
> quite busy these days" mode too ;) So sorry, no test case, at least
> not now.
