Re: git: 9ac6eda6c6a3 - main - pipe: try to skip locking the pipe if a non-blocking fd is used

On 8/17/22 8:39 AM, Gleb Smirnoff wrote:
> On Wed, Aug 17, 2022 at 08:34:22AM -0700, Gleb Smirnoff wrote:
> T> This also breaks API. Although not explicitly narrated by POSIX or our
> T> documentation, but there is a strong contract that, if application had
> T> received a non-blocking fd from event dispatcher (kevent, poll, select)
> T> as writable, then it is possible to write thre non-zero bytes with next
> T> syscall.
> 
> Actually for poll(2) and kevent(2) you can almost read this contract between
> the lines:
> 
>       POLLWRNORM     Normal data may be written without blocking.
> 
>       EVFILT_WRITE        Takes a descriptor as the identifier, and returns
>                           whenever it is possible to write to the descriptor.
>                           For sockets, pipes and fifos, data will contain the
>                           amount of space remaining in the write buffer.  The
>                           filter will set EV_EOF when the reader disconnects,
>                           and for the fifo case, this will be cleared when a
>                           new reader connects.  Note that this filter is not
>                           supported for vnodes.
> 
> So with this change it may happen that previous return of poll or kevent
> returned incorrect information.

While I largely agree with your sentiment, I think the actual contract is a
bit weaker than you stated and something more like:

"If a non-blocking fd becomes writable and the event is published, at least
  one thread will be able to write without blocking."

That is, the contract you stated is true when there is a single writer, but
with multiple writers it is not true.  You might get a kevent back that says
you have X bytes of room to write, yet be able to write less than X because
of concurrent writes in other threads.

-- 
John Baldwin