bug-gawk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gawk] bug report on PROCINFO[,"READ_TIMEOUT"]


From: Andrew J. Schorr
Subject: Re: [bug-gawk] bug report on PROCINFO[,"READ_TIMEOUT"]
Date: Tue, 5 May 2015 18:24:05 -0400
User-agent: Mutt/1.5.23 (2014-03-12)

Hi,

On Tue, May 05, 2015 at 03:00:04PM -0500, Alejandro Mendoza wrote:
> If a timeout occurs on reading (stdin, file or network), a subsequent
> reading aborts immediately (no timeout), even after changing the timeout
> value.
> 
> The bug is very simple to replicate, this very short code typed at the
> command line can show it:
> 
> awk 'BEGIN {infile="/dev/stdin"; PROCINFO[infile,"READ_TIMEOUT"]=2000;
> getline    < infile; print "read 1: " $0; print "next input"; $0="";
> PROCINFO[infile,"READ_TIMEOUT"]="5000";getline <infile; print "read 2: "
> $0}'
> 
> If I let the first read to time out, the second aborts immediately (even if
> I set it to 0 to wait forever). If I type something and hit <enter> before
> timing out, the second read works as it should.

I know it seems counterintuitive, but this is not a bug.  When a read times
out, gawk versions through 4.1.X consider this to be an I/O error and close the
file.  Subsequent reads will return an error.  Hint: try checking the return
code from getline.

The good news is that a solution for this is already in the git master branch.
There is a new retryable I/O feature that enables the use of non-blocking I/O
and supports the read timeout feature in a more sensible way.  If you'd like
early access to this capability, you will need to grab a copy of the master
branch from git.  Note that the behavior will be the same as before unless you
set PROCINFO[input-file, "RETRY"].  Please refer to the manual for more
details.

Regards,
Andy



reply via email to

[Prev in Thread] Current Thread [Next in Thread]