Re: [PATCH 1/2] run-parallel: rename set_nonblocking to set_nonblocking_or_die

From: Torsten Bögershausen <tboegi@web.de>
Date: Nov 5, 2015, 06:07 UTC
Message-ID: <563AF229.1060302@web.de>
In-Reply-To: <1446677029-10745-2-git-send-email-sbeller@google.com>

On 11/04/2015 11:43 PM, Stefan Beller wrote:

Show 9 quoted lines

> Discussion turned out a warning is not enough, but we need to die in case
> of blocking output as we can lockup the child processes.
>
> Junio wrote:
>> Imagine that we are running two things A and B at the same time.  We
>> ask poll(2) and it says both A and B have some data ready to be
>> read, and we try to read from A.  strbuf_read_once() would try to
>> read up to 8K, relying on the fact that you earlier set the IO to be
>> nonblock.

(Jumping into an old discussion, I may be off topic)

When we want to make really sure, not to get stucked, we can do like this:

ssize_t xread_nonblock(int fd, void *buf, size_t len)
{
     ssize_t nr;
     if (len > MAX_IO_SIZE)
         len = MAX_IO_SIZE;
     nr = read(fd, buf, len);
     if (nr < 0) {
        if (errno == EWOULDBLOCK)
             errno = EAGAIN;
      return nr;
}

Once poll() returns POLLIN as set on a fd, we can safely call read() once without getting stucked. "Data can be read without blocking".

And this work regardless if the fd blocking or not, so from that point of view, the set_nonblocking() is not needed at all.

The major question is, if the poll() works under Windows, (and I haven't found time to dig further)