sendmmsg). Note that implementing this
in a Linux-compatible manner has low overhead, since Linux only checks
it between packets and never interrupts a wait because of this timeout
(source: http://man7.org/linux/man-pages/man2/recvmmsg.2.html ).
> [snip]
--
Jilles Tjoelker
___
On Sun, Jan 17, 2016 at 10:18:53PM +0100, Jilles Tjoelker wrote:
> On Sat, Jan 16, 2016 at 10:25:34PM +0200, Konstantin Belousov wrote:
> > On Sat, Jan 16, 2016 at 09:56:57PM +0200, Konstantin Belousov wrote:
> > > After thinking some more, I believe I managed to construct a pos
e leaving cancellation pending. This
seems conceptually possible but adds some code to the common path for
cancellation points. A new version of pthread_testcancel() with a return
value would be needed.
--
Jilles Tjoelker
___
freebsd-net@freebsd.or
return (0);
}
A blocking accept (and some other operations) is waiting on
&so->so_timeo. Once it wakes up, it will detect the SBS_CANTRCVMORE bit.
A spurious wakeup on so->so_timeo appears harmless (sleep retried)
except when lingering on close (SO_LINGER) so this should be fairly
safe.
ead out of accept(2) (at least without resorting to
> signals).
Pthread cancellation works better than raw signals for this use case. In
a proper implementation such as in FreeBSD 9.0 or newer and used
properly, it allows avoiding the resource leak that may happen
tations. C99
recognized this need and created a way to do it, which looks like
uint16_t addr_type[];. This adds any necessary padding and allows access
to however many elements have been allocated. Also, if it is not at the
end of a struct it is an error.
Using this new construct requires cod
;
and "connection closed after poll() returned something" are useful in
reasoning about this.
Ports people have complained about poll() behaviour before, are there
configure scripts that attempt to check if we ever return POLLHUP alone
and only check for POLLIN if not?
--
Jilles T
