Re: pipe read returning EAGAIN

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sun, Feb 07, 2016 at 03:23:58PM +0100, Manuel Bouyer wrote:
> It looks like the read(2) syscall returns a EAGAIN when the caller
> expect it to block if there's no data available.

I could capture the pipe setup before getting the stream of EAGAIN:
 20110      1 nagios   EMUL  "netbsd"
 20110      1 nagios   CALL  read(3,0xbb51a000,0x80000)
 20110      1 nagios   GIO   fd 3 read 114 bytes
       "job_id=5513\0type=0\0command=/usr/pkg/libexec/nagios/check_snmp -H 10.\
        128.12.0 -o .1.3.6.1.2.1.1.5.0\0timeout=60\0\^A\0\0\0"
 20110      1 nagios   RET   read 114/0x72
 20110      1 nagios   CALL  __gettimeofday50(0xbb59d08c,0)
 20110      1 nagios   RET   __gettimeofday50 0
 20110      1 nagios   CALL  __gettimeofday50(0xbf7fe4a4,0)
 20110      1 nagios   RET   __gettimeofday50 0
 20110      1 nagios   CALL  __gettimeofday50(0xbf7fe4ac,0)
 20110      1 nagios   RET   __gettimeofday50 0
 20110      1 nagios   CALL  __gettimeofday50(0xbf7fe468,0)
 20110      1 nagios   RET   __gettimeofday50 0
 20110      1 nagios   CALL  pipe
 20110      1 nagios   RET   pipe 4, 5
 20110      1 nagios   CALL  pipe
 20110      1 nagios   RET   pipe 6, 7
 20110      1 nagios   CALL  fcntl(4,4,4)
 20110      1 nagios   RET   fcntl 0
 20110      1 nagios   CALL  fcntl(6,4,4)
 20110      1 nagios   RET   fcntl 0
 20110      1 nagios   CALL  fork
 20110      1 nagios   RET   fork 1822/0x71e
 20110      1 nagios   CALL  close(5)
 20110      1 nagios   RET   close 0
 20110      1 nagios   CALL  close(7)
 20110      1 nagios   RET   close 0
 20110      1 nagios   CALL  read(4,0xbf7fd4e0,0x1000)
 20110      1 nagios   RET   read -1 errno 35 Resource temporarily unavailable
 20110      1 nagios   CALL  read(4,0xbf7fd4e0,0x1000)
 20110      1 nagios   RET   read -1 errno 35 Resource temporarily unavailable
 20110      1 nagios   CALL  read(4,0xbf7fd4e0,0x1000)
 20110      1 nagios   RET   read -1 errno 35 Resource temporarily unavailable

If I read this properly, the 2 fnctl calls do a F_SETFL with
O_NONBLOCK. So it looks normal for the read to return EAGAIN in this case.

What I find strange is that there's no call to poll(2) or select(2)
before before the call to read(2).
If I read the sources properly the process should use poll(2) before calling
read(2). I can't see why this would not show up in the ktrace output.



-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--