From owner-freebsd-net@freebsd.org Mon Jan 18 10:37:03 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A536CA86EED for ; Mon, 18 Jan 2016 10:37:03 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 82A661FAB for ; Mon, 18 Jan 2016 10:37:03 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 81D9BA86EE9; Mon, 18 Jan 2016 10:37:03 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67613A86EE8; Mon, 18 Jan 2016 10:37:03 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC4CC1FAA; Mon, 18 Jan 2016 10:37:02 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id b14so115681986wmb.1; Mon, 18 Jan 2016 02:37:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xpxqdNf9r5dQJyHyblaHo48LH//gjFPotsBieLUcaQ4=; b=PVhFvDxwUq0W2TcGKoheMWZerfTVvhAsGiNgkxy5rSwNufzQ34lkyKYrpsI+9QTzQ7 prEGX/2IHl5Or0xPRIFeSYM8qMb9dC8VQTp1ZWrmWqsxBUFO67cSbZQPNnLs3GsqUjdS TunyNKuNboYuVS4OlaGgfMCnybsWyJt+j57XDN1Efz+dmqQFYKGBPc6ZkKMVuRDFozqr Tn5njjroQ/CdmejtmL3p5EGVH9HzkJ9Q5OrROt6LhUt+3xaavL7qyayV3Fmbb9lV5axq BlOBtxHmk1Y9OdU7sVd80mzxKsVJHaMuMmequpZ/HV7TyhdwgaAOadvFcgrrYddUTQla +2oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xpxqdNf9r5dQJyHyblaHo48LH//gjFPotsBieLUcaQ4=; b=dM9TAB6yeJwpc8Y0QQOkUbDo5oBDR2/YIEVnMT0ZB0LyNkwyW/xhquETHeY6AkciXN 7mjVuxFktbLV/6SV/9TuV+uYAs4Mm9Sp9XbDQzg5tFV82yUDqyQ17GkLFgHzFwS6Mas1 ooANXP/u4FMEbqD1GxuqhLPGwPVpvQtX1JhbzPXF1AJeWe40gS0U7PYtDd8TOSYQbhes yXm/UOny+kHGKA+u9Knq+EicDBUdlBG3aH/fjpfv3f31xptBrtR6C0dbz+1ckkkOI2Vz NK/m/NMEQGn453zESv2XIbkoLab09dzoaTswQinIKfJBEyQgCVT2NyLvzSpPuBuQm2+x FjdA== X-Gm-Message-State: AG10YOTtId8OPWJtB4C9UbNIL2PajQ14stC1OinmPIX3crYxfv4Q71z2ZdCmIgIs6U6C9UelIFofPfhAAi6M8g== MIME-Version: 1.0 X-Received: by 10.28.1.23 with SMTP id 23mr11759270wmb.37.1453113421506; Mon, 18 Jan 2016 02:37:01 -0800 (PST) Received: by 10.28.136.148 with HTTP; Mon, 18 Jan 2016 02:37:01 -0800 (PST) In-Reply-To: <20160118044826.GS3942@kib.kiev.ua> References: <20160108075815.3243.qmail@f5-external.bushwire.net> <20160108204606.G2420@besplex.bde.org> <20160113080349.GC72455@kib.kiev.ua> <20160116195657.GJ3942@kib.kiev.ua> <20160116202534.GK3942@kib.kiev.ua> <20160117211853.GA37847@stack.nl> <20160118044826.GS3942@kib.kiev.ua> Date: Mon, 18 Jan 2016 12:37:01 +0200 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Boris Astardzhiev To: Konstantin Belousov Cc: Jilles Tjoelker , net@freebsd.org, threads@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 10:37:03 -0000 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 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). >