Date: Mon, 18 Jan 2016 06:48:26 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Jilles Tjoelker <jilles@stack.nl> Cc: Boris Astardzhiev <boris.astardzhiev@gmail.com>, net@freebsd.org, threads@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160118044826.GS3942@kib.kiev.ua> In-Reply-To: <20160117211853.GA37847@stack.nl> References: <20160108075815.3243.qmail@f5-external.bushwire.net> <CAJ-VmonYPhcN-gikuYQU_k5GaTAqTijoxR_0ORV4BZqsHMRJSg@mail.gmail.com> <20160108204606.G2420@besplex.bde.org> <CAJ-Vmom26mukSv3JmsmNiAONvpc6f1bQ%2BujO25qefGHY=5przA@mail.gmail.com> <CAP=KkTwG0SVUmrBuWm33EC-tG4tMTdF5rLZQ_u6G1=-ujnfjkA@mail.gmail.com> <20160113080349.GC72455@kib.kiev.ua> <CAP=KkTxVaqZvigg78Dg%2Bv8kuTCaZyky8x15NHqD9uabuRKRkMw@mail.gmail.com> <20160116195657.GJ3942@kib.kiev.ua> <20160116202534.GK3942@kib.kiev.ua> <20160117211853.GA37847@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Added threads@ where this discussion is more appropriate. On Sun, Jan 17, 2016 at 10:18:53PM +0100, Jilles Tjoelker wrote: > This will typically work (if the cancellation occurs while blocked > inside __sys_recvmsg()) but has the usual problem of relying on [EINTR]: > lost wakeups. This is certainly less bad than using the interposable > recvmsg(), though, which would discard the already received data. > > As a slight modification, the first recvmsg could use the interposable > version, since there is no pending data at that point. This avoids > needing to call pthread_testcancel() manually. > > The regular cancellation code closes this race window using the > undocumented thr_wake() system call, on the thread itself, in the signal > handler for the cancellation signal. This causes the next attempt to > sleep(9) to fail with [EINTR]. (On another note, it appears to be > possible for user code (cleanup handlers and pthread_key_create() > destructors) to be called with thr_wake() still active, if the > cancellation signal handler is called immediately after the cancellation > point system call returns.) > > The race in recvmmsg could be removed using this mechanism but it > requires either a separate version of recvmmsg in libthr or a new > interface in libthr. I imagine the new interface as a new cancellation > type which causes cancellation point functions such as recvmsg() to fail > with a new errno when cancelled while 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. Yes, I should have remembered about TDP_WAKEUP. In fact, this discussion and recvmmsg() skeleton structured my understanding of the better split between libc and libthr. I start thinking that libthr should not interpose most of the syscalls. Instead, libthr should interpose (wrappers around) thr_cancel_enter*() and thr_cancel_leave(), the body of the cancellable syscalls should live in libc. The benefits are removal of double implementation of cancellable syscalls, more compact interface between libc and libthr, and potentially we can grow an _np extension which would allow user libraries to correctly implement composable cancellable functions (as needed for sendmmsg).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160118044826.GS3942>