Date: Mon, 18 Jan 2016 12:37:01 +0200 From: Boris Astardzhiev <boris.astardzhiev@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Jilles Tjoelker <jilles@stack.nl>, net@freebsd.org, threads@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <CAP=KkTy3J=k7hokGhohcGXv%2BWLnaxJmiAPxqmX9FHt7k0=Dp7Q@mail.gmail.com> In-Reply-To: <20160118044826.GS3942@kib.kiev.ua> 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> <20160118044826.GS3942@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Sorry for the delay of my reply. As far as I understand pthread_testcancel() is not necessary in the recvmmsg syscall since cancellation is not quite common among apps. But if there is cancellation attempts as long as I use __sys_recvmsg() instead of the interposing approach on a cancel attempt recvmmsg() will return EINTR which will get me out? Secondly, I guess it's better to use __sys_sendmmsg() similarly instead of the insterposing table regarding sendmmsg(). Lastly, regarding the manpage - should I extend send/recv(2) for the new calls or create new manpage files? Best regards, Boris Astardzhiev On Mon, Jan 18, 2016 at 6:48 AM, Konstantin Belousov <kostikbel@gmail.com> wrote: > 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?CAP=KkTy3J=k7hokGhohcGXv%2BWLnaxJmiAPxqmX9FHt7k0=Dp7Q>