Date: Wed, 17 Aug 2022 09:04:02 -0700 From: John Baldwin <jhb@FreeBSD.org> To: Gleb Smirnoff <glebius@freebsd.org>, Mateusz Guzik <mjg@freebsd.org> Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 9ac6eda6c6a3 - main - pipe: try to skip locking the pipe if a non-blocking fd is used Message-ID: <05eb9b32-d466-57c2-a01f-d34955873ac8@FreeBSD.org> In-Reply-To: <Yv0LqtsEbA5SB5hS@FreeBSD.org> References: <202208171423.27HENpvp024623@gitrepo.freebsd.org> <Yv0KfpO9i4lR9LQm@FreeBSD.org> <Yv0LqtsEbA5SB5hS@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?05eb9b32-d466-57c2-a01f-d34955873ac8>