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 <kostik...@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). > _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
