From owner-freebsd-threads@freebsd.org Mon Jan 18 04:48:32 2016 Return-Path: Delivered-To: freebsd-threads@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 BE566A86A56 for ; Mon, 18 Jan 2016 04:48:32 +0000 (UTC) (envelope-from kostikbel@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 A29CB1BFD for ; Mon, 18 Jan 2016 04:48:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9D945A86A53; Mon, 18 Jan 2016 04:48:32 +0000 (UTC) Delivered-To: threads@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 8428CA86A50; Mon, 18 Jan 2016 04:48:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 283401BFA; Mon, 18 Jan 2016 04:48:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u0I4mQTo015893 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 18 Jan 2016 06:48:27 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u0I4mQTo015893 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u0I4mQTg015892; Mon, 18 Jan 2016 06:48:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 18 Jan 2016 06:48:26 +0200 From: Konstantin Belousov To: Jilles Tjoelker Cc: Boris Astardzhiev , net@freebsd.org, threads@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160117211853.GA37847@stack.nl> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 04:48:32 -0000 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). From owner-freebsd-threads@freebsd.org Mon Jan 18 10:37:03 2016 Return-Path: Delivered-To: freebsd-threads@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 A75E8A86EEE 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 84D331FAC for ; Mon, 18 Jan 2016 10:37:03 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 82272A86EEB; Mon, 18 Jan 2016 10:37:03 +0000 (UTC) Delivered-To: threads@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-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on 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). > From owner-freebsd-threads@freebsd.org Mon Jan 18 14:08:17 2016 Return-Path: Delivered-To: freebsd-threads@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 5DE56A878F9 for ; Mon, 18 Jan 2016 14:08:17 +0000 (UTC) (envelope-from kostikbel@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 44C82176D for ; Mon, 18 Jan 2016 14:08:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 41161A878F7; Mon, 18 Jan 2016 14:08:17 +0000 (UTC) Delivered-To: threads@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 40946A878F6; Mon, 18 Jan 2016 14:08:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B2198176C; Mon, 18 Jan 2016 14:08:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u0IE8CrR054635 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 18 Jan 2016 16:08:12 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u0IE8CrR054635 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u0IE8Boc054634; Mon, 18 Jan 2016 16:08:11 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 18 Jan 2016 16:08:11 +0200 From: Konstantin Belousov To: Boris Astardzhiev Cc: Jilles Tjoelker , net@freebsd.org, threads@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160118140811.GW3942@kib.kiev.ua> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 14:08:17 -0000 On Mon, Jan 18, 2016 at 12:37:01PM +0200, Boris Astardzhiev wrote: > 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? Yes. The corner case is the cancellation attempt (SIGCANCEL == SIGTHR) coming while the thread is executing code around the syscall. > > Secondly, I guess it's better to use __sys_sendmmsg() similarly instead of > the > insterposing table regarding sendmmsg(). Sure, sendmmsg and recvmmsg are same. > > Lastly, regarding the manpage - should I extend send/recv(2) for the new > calls or > create new manpage files? IMO it is more logical to extend the existing page than write a new one. From owner-freebsd-threads@freebsd.org Tue Jan 19 11:58:30 2016 Return-Path: Delivered-To: freebsd-threads@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 E4272A87472 for ; Tue, 19 Jan 2016 11:58:30 +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 BFF231635 for ; Tue, 19 Jan 2016 11:58:30 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id BB78CA8746F; Tue, 19 Jan 2016 11:58:30 +0000 (UTC) Delivered-To: threads@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 9F9F5A8746B; Tue, 19 Jan 2016 11:58:30 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 232771633; Tue, 19 Jan 2016 11:58:30 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id 123so88281065wmz.0; Tue, 19 Jan 2016 03:58:30 -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=cjJvvthu0PsGR0vHaheXs36H0B2fWNcn0AiSP3C/TCc=; b=DjJmWbIUkELuUzOk0e1exGOj9LXCKZmfFOcqSx8abE0sibrXej/Y14e8gOkhdxYAqY boI7/tcO/3s2XAU6ubask5Aym5z5J7zkSplutn6k9lZbI/et/1nq6oiv/MkZNFhPriaI HJCcBzKoCWfDTgh/cTuwXsroPTkGD0DD5Pyd4CkqycPjOrgMdEMFMb21u3fMGuVK/1Ws Y5jZWFBITXQedzOwR1EDvuzp3ioWMBEoNvV8o3/eEVNO+EZztGPwMCYfKI/UqdFQfNd/ 7vvQBvXrd1D8s/q7J2fXdmiMVGzO/HrIQiAQr2R00vCq34d5bNw4/QKFYSWMPdj42DtP p5gA== 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=cjJvvthu0PsGR0vHaheXs36H0B2fWNcn0AiSP3C/TCc=; b=EH6xrZsMATTJ8HxPtAvBWNbxMX+ZwPBfhybT6VZ3bAkD9SZvw9cgbk6D1f3lZmCVF9 dpPxTtSftGxdNzW9m0reQjSnR4yzE0ehjMrmtrePJyN5RKh9VkGdUgyKXFZG7JzbC8SA +1S3H1N74ec/GMx4IniCxf6qMZ/clb1JBzh5p9nbvNLIRKt0WR19LM+lWq4J2DcluPdH f/GeieW0xR8VABjqI022wHamTFT3+y7Z7g0ekEySre3bGRb9MA0psZJPzvhxTlZvcHt5 xT5OsiyT/Hx5CtT8fjlUP5eR2cdilMOoBXTz0XNmcFhTW4NaPM/UY2fb1z5RZDyHGm7M y0JQ== X-Gm-Message-State: AG10YORzGC1ywMcduBdWWy2JxY/xyaaZj7zzOgXpIEeUSZUBXGoLhV0ZE5Es7Q3EjeJlR79+BxY0IsraniL3tg== MIME-Version: 1.0 X-Received: by 10.28.63.22 with SMTP id m22mr17456074wma.59.1453204708288; Tue, 19 Jan 2016 03:58:28 -0800 (PST) Received: by 10.28.136.148 with HTTP; Tue, 19 Jan 2016 03:58:27 -0800 (PST) In-Reply-To: <20160118140811.GW3942@kib.kiev.ua> References: <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> <20160118140811.GW3942@kib.kiev.ua> Date: Tue, 19 Jan 2016 13:58:27 +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: multipart/mixed; boundary=001a114b3ebc6c912e0529ae96fb X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 11:58:31 -0000 --001a114b3ebc6c912e0529ae96fb Content-Type: text/plain; charset=UTF-8 Hello, I removed the pthread_testcancel() calls and cut the interposing stuff from my patch as suggested. I extended the send/recv(2) manpages regarding the mm calls. Comments and suggestions? Best regards, Boris Astardzhiev On Mon, Jan 18, 2016 at 4:08 PM, Konstantin Belousov wrote: > On Mon, Jan 18, 2016 at 12:37:01PM +0200, Boris Astardzhiev wrote: > > 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? > Yes. > > The corner case is the cancellation attempt (SIGCANCEL == SIGTHR) coming > while the thread is executing code around the syscall. > > > > > Secondly, I guess it's better to use __sys_sendmmsg() similarly instead > of > > the > > insterposing table regarding sendmmsg(). > Sure, sendmmsg and recvmmsg are same. > > > > > Lastly, regarding the manpage - should I extend send/recv(2) for the new > > calls or > > create new manpage files? > IMO it is more logical to extend the existing page than write a new one. > --001a114b3ebc6c912e0529ae96fb Content-Type: text/plain; charset=US-ASCII; name="sendrecvmmsg-libconly3.diff" Content-Disposition: attachment; filename="sendrecvmmsg-libconly3.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ijlch3460 ZGlmZiAtLWdpdCBhL2xpYi9saWJjL2luY2x1ZGUvbmFtZXNwYWNlLmggYi9saWIvbGliYy9pbmNs dWRlL25hbWVzcGFjZS5oCmluZGV4IDczOWQ3YjEuLmM5NTgyOWUgMTAwNjQ0Ci0tLSBhL2xpYi9s aWJjL2luY2x1ZGUvbmFtZXNwYWNlLmgKKysrIGIvbGliL2xpYmMvaW5jbHVkZS9uYW1lc3BhY2Uu aApAQCAtMjA4LDYgKzIwOCw3IEBACiAjZGVmaW5lCQlyZWFkdgkJCQlfcmVhZHYKICNkZWZpbmUJ CXJlY3Zmcm9tCQkJX3JlY3Zmcm9tCiAjZGVmaW5lCQlyZWN2bXNnCQkJCV9yZWN2bXNnCisjZGVm aW5lCQlyZWN2bW1zZwkJCV9yZWN2bW1zZwogI2RlZmluZQkJc2VsZWN0CQkJCV9zZWxlY3QKICNk ZWZpbmUJCXNlbV9jbG9zZQkJCV9zZW1fY2xvc2UKICNkZWZpbmUJCXNlbV9kZXN0cm95CQkJX3Nl bV9kZXN0cm95CkBAIC0yMjAsNiArMjIxLDcgQEAKICNkZWZpbmUJCXNlbV91bmxpbmsJCQlfc2Vt X3VubGluawogI2RlZmluZQkJc2VtX3dhaXQJCQlfc2VtX3dhaXQKICNkZWZpbmUJCXNlbmRtc2cJ CQkJX3NlbmRtc2cKKyNkZWZpbmUJCXNlbmRtbXNnCQkJX3NlbmRtbXNnCiAjZGVmaW5lCQlzZW5k dG8JCQkJX3NlbmR0bwogI2RlZmluZQkJc2V0c29ja29wdAkJCV9zZXRzb2Nrb3B0CiAvKiNkZWZp bmUJCXNpZ2FjdGlvbgkJCV9zaWdhY3Rpb24qLwpkaWZmIC0tZ2l0IGEvbGliL2xpYmMvaW5jbHVk ZS91bi1uYW1lc3BhY2UuaCBiL2xpYi9saWJjL2luY2x1ZGUvdW4tbmFtZXNwYWNlLmgKaW5kZXgg ZjMxZmE3YS4uMDIzMzM0OCAxMDA2NDQKLS0tIGEvbGliL2xpYmMvaW5jbHVkZS91bi1uYW1lc3Bh Y2UuaAorKysgYi9saWIvbGliYy9pbmNsdWRlL3VuLW5hbWVzcGFjZS5oCkBAIC0xODksNiArMTg5 LDcgQEAKICN1bmRlZgkJcmVhZHYKICN1bmRlZgkJcmVjdmZyb20KICN1bmRlZgkJcmVjdm1zZwor I3VuZGVmCQlyZWN2bW1zZwogI3VuZGVmCQlzZWxlY3QKICN1bmRlZgkJc2VtX2Nsb3NlCiAjdW5k ZWYJCXNlbV9kZXN0cm95CkBAIC0yMDEsNiArMjAyLDcgQEAKICN1bmRlZgkJc2VtX3VubGluawog I3VuZGVmCQlzZW1fd2FpdAogI3VuZGVmCQlzZW5kbXNnCisjdW5kZWYJCXNlbmRtbXNnCiAjdW5k ZWYJCXNlbmR0bwogI3VuZGVmCQlzZXRzb2Nrb3B0CiAjdW5kZWYJCXNpZ2FjdGlvbgpkaWZmIC0t Z2l0IGEvbGliL2xpYmMvc3lzL01ha2VmaWxlLmluYyBiL2xpYi9saWJjL3N5cy9NYWtlZmlsZS5p bmMKaW5kZXggZTRmZTFiMi4uNWY4YjY5OSAxMDA2NDQKLS0tIGEvbGliL2xpYmMvc3lzL01ha2Vm aWxlLmluYworKysgYi9saWIvbGliYy9zeXMvTWFrZWZpbGUuaW5jCkBAIC0yOCw2ICsyOCw4IEBA IFNSQ1MrPSBmdXRpbWVucy5jIHV0aW1lbnNhdC5jCiBOT0FTTSs9IGZ1dGltZW5zLm8gdXRpbWVu c2F0Lm8KIFBTRVVETys9IF9mdXRpbWVucy5vIF91dGltZW5zYXQubwogCitTUkNTKz0gcmVjdm1t c2cuYyBzZW5kbW1zZy5jCisKIElOVEVSUE9TRUQgPSBcCiAJYWNjZXB0IFwKIAlhY2NlcHQ0IFwK ZGlmZiAtLWdpdCBhL2xpYi9saWJjL3N5cy9TeW1ib2wubWFwIGIvbGliL2xpYmMvc3lzL1N5bWJv bC5tYXAKaW5kZXggN2IzMjU3Yy4uNzI0ZTFiNCAxMDA2NDQKLS0tIGEvbGliL2xpYmMvc3lzL1N5 bWJvbC5tYXAKKysrIGIvbGliL2xpYmMvc3lzL1N5bWJvbC5tYXAKQEAgLTM5OSw2ICszOTksOCBA QCBGQlNEXzEuNCB7CiAJdXRpbWVuc2F0OwogCW51bWFfc2V0YWZmaW5pdHk7CiAJbnVtYV9nZXRh ZmZpbml0eTsKKwlzZW5kbW1zZzsKKwlyZWN2bW1zZzsKIH07CiAKIEZCU0Rwcml2YXRlXzEuMCB7 CkBAIC0xMDUxLDQgKzEwNTMsNiBAQCBGQlNEcHJpdmF0ZV8xLjAgewogCWdzc2Rfc3lzY2FsbDsK IAlfX2xpYmNfaW50ZXJwb3Npbmdfc2xvdDsKIAlfX2xpYmNfc2lnd2FpdDsKKwlfc2VuZG1tc2c7 CisJX3JlY3ZtbXNnOwogfTsKZGlmZiAtLWdpdCBhL2xpYi9saWJjL3N5cy9yZWN2LjIgYi9saWIv bGliYy9zeXMvcmVjdi4yCmluZGV4IDMyNmU3ZmYuLjgxYTAyMDEgMTAwNjQ0Ci0tLSBhL2xpYi9s aWJjL3N5cy9yZWN2LjIKKysrIGIvbGliL2xpYmMvc3lzL3JlY3YuMgpAQCAtMzQsOCArMzQsOSBA QAogLlNoIE5BTUUKIC5ObSByZWN2ICwKIC5ObSByZWN2ZnJvbSAsCi0uTm0gcmVjdm1zZwotLk5k IHJlY2VpdmUgYSBtZXNzYWdlIGZyb20gYSBzb2NrZXQKKy5ObSByZWN2bXNnICwKKy5ObSByZWN2 bW1zZworLk5kIHJlY2VpdmUgbWVzc2FnZShzKSBmcm9tIGEgc29ja2V0CiAuU2ggTElCUkFSWQog LkxiIGxpYmMKIC5TaCBTWU5PUFNJUwpAQCAtNDcsMTEgKzQ4LDE1IEBACiAuRm4gcmVjdmZyb20g ImludCBzIiAidm9pZCAqYnVmIiAic2l6ZV90IGxlbiIgImludCBmbGFncyIgInN0cnVjdCBzb2Nr YWRkciAqIHJlc3RyaWN0IGZyb20iICJzb2NrbGVuX3QgKiByZXN0cmljdCBmcm9tbGVuIgogLkZ0 IHNzaXplX3QKIC5GbiByZWN2bXNnICJpbnQgcyIgInN0cnVjdCBtc2doZHIgKm1zZyIgImludCBm bGFncyIKKy5GdCBpbnQKKy5GbiByZWN2bW1zZyAiaW50IHMiICJzdHJ1Y3QgbW1zZ2hkciAqbXNn dmVjIiAiaW50IHZsZW4iICJpbnQgZmxhZ3MiCiAuU2ggREVTQ1JJUFRJT04KIFRoZQogLkZuIHJl Y3Zmcm9tCiBhbmQKIC5GbiByZWN2bXNnCithbmQKKy5GbiByZWN2bW1zZwogc3lzdGVtIGNhbGxz CiBhcmUgdXNlZCB0byByZWNlaXZlIG1lc3NhZ2VzIGZyb20gYSBzb2NrZXQsCiBhbmQgbWF5IGJl IHVzZWQgdG8gcmVjZWl2ZSBkYXRhIG9uIGEgc29ja2V0IHdoZXRoZXIgb3Igbm90CkBAIC04NCw4 ICs4OSwyNSBAQCBudWxsIHBvaW50ZXIgcGFzc2VkIGFzIGl0cwogLkZhIGZyb20KIGFyZ3VtZW50 LgogLlBwCi1BbGwgdGhyZWUgcm91dGluZXMgcmV0dXJuIHRoZSBsZW5ndGggb2YgdGhlIG1lc3Nh Z2Ugb24gc3VjY2Vzc2Z1bAotY29tcGxldGlvbi4KK1RoZQorLkZuIHJlY3ZtbXNnCitmdW5jdGlv biBpcyB1c2VkIHRvIHJlY2VpdmUgbXVsdGlwbGUKK21lc3NhZ2VzIGF0IGEgY2FsbC4KK1RoZWly IG51bWJlcgoraXMgc3VwcGxpZWQgYnkKKy5GYSB2bGVuCisobGltaXRlZCB0byAxMDI0KS4KK1Ro ZSBtZXNzYWdlcyBhcmUgcGxhY2VkIGluIHRoZQorLkZhIG1zZ3ZlYwordmVjdG9yIGFmdGVyIHJl Y2VwdGlvbi4KK1RoZSBzaXplIG9mIGVhY2ggcmVjZWl2ZWQgbWVzc2FnZSBpcyBwbGFjZWQgaW4g dGhlCisuRmEgbXNnX2xlbgorZmllbGQgb2YgZWFjaCBlbGVtZW50IG9mIHRoZSB2ZWN0b3IuCisu UHAKK1RoZSBmaXJzdCB0aHJlZSByb3V0aW5lcyByZXR1cm4gdGhlIGxlbmd0aCBvZiB0aGUgbWVz c2FnZSBvbiBzdWNjZXNzZnVsCitjb21wbGV0aW9uIHdoZXJlYXMKKy5GbiByZWN2bW1zZworcmV0 dXJucyB0aGUgbnVtYmVyIG9mIHJlY2VpdmVkIG1lc3NhZ2VzLgogSWYgYSBtZXNzYWdlIGlzIHRv byBsb25nIHRvIGZpdCBpbiB0aGUgc3VwcGxpZWQgYnVmZmVyLAogZXhjZXNzIGJ5dGVzIG1heSBi ZSBkaXNjYXJkZWQgZGVwZW5kaW5nIG9uIHRoZSB0eXBlIG9mIHNvY2tldAogdGhlIG1lc3NhZ2Ug aXMgcmVjZWl2ZWQgZnJvbSAoc2VlCkBAIC0xMDAsNyArMTIyLDkgQEAgaW4gd2hpY2ggY2FzZSB0 aGUgdmFsdWUKIC5WYSBlcnJubwogaXMgc2V0IHRvCiAuRXIgRUFHQUlOIC4KLVRoZSByZWNlaXZl IGNhbGxzIG5vcm1hbGx5IHJldHVybiBhbnkgZGF0YSBhdmFpbGFibGUsCitUaGUgcmVjZWl2ZSBj YWxscyBleGNlcHQKKy5GbiByZWN2bW1zZworbm9ybWFsbHkgcmV0dXJuIGFueSBkYXRhIGF2YWls YWJsZSwKIHVwIHRvIHRoZSByZXF1ZXN0ZWQgYW1vdW50LAogcmF0aGVyIHRoYW4gd2FpdGluZyBm b3IgcmVjZWlwdCBvZiB0aGUgZnVsbCBhbW91bnQgcmVxdWVzdGVkOwogdGhpcyBiZWhhdmlvciBp cyBhZmZlY3RlZCBieSB0aGUgc29ja2V0LWxldmVsIG9wdGlvbnMKQEAgLTI5MCw5ICszMTQsMzQg QEAgY29udHJvbCBkYXRhIHdlcmUgZGlzY2FyZGVkIGR1ZSB0byBsYWNrIG9mIHNwYWNlIGluIHRo ZSBidWZmZXIKIGZvciBhbmNpbGxhcnkgZGF0YS4KIC5EdiBNU0dfT09CCiBpcyByZXR1cm5lZCB0 byBpbmRpY2F0ZSB0aGF0IGV4cGVkaXRlZCBvciBvdXQtb2YtYmFuZCBkYXRhIHdlcmUgcmVjZWl2 ZWQuCisuUHAKK1RoZQorLkZuIHJlY3ZtbXNnCitzeXN0ZW0gY2FsbCB1c2VzIHRoZQorLkZhIG1t c2doZHIKK3N0cnVjdHVyZS4gSXRzIGZvcm0gaXMgYXMgZm9sbG93cywgYXMgZGVmaW5lZCBpbgor LkluIHN5cy9zb2NrZXQuaCA6CisuQmQgLWxpdGVyYWwKK3N0cnVjdCBtbXNnaGRyIHsKKwlzdHJ1 Y3QgbXNnaGRyCSBtc2dfaGRyOwkvKiBtZXNzYWdlIGhlYWRlciAqLworCXVuc2lnbmVkIGludAkg bXNnX2xlbjsJLyogbWVzc2FnZSBsZW5ndGggKi8KK307CisuRWQKKy5QcAorRm9yCisuRmEgbXNn X2hkcgorc2VlIGFib3ZlLiBPbiBkYXRhIHJlY2VwdGlvbiB0aGUKKy5GYSBtc2dfbGVuCitmaWVs ZCBpcyB1cGRhdGVkIHRvIHRoZSBsZW5ndGggb2YgdGhlIHJlY2VpdmVkIG1lc3NhZ2UuIE9uCitk YXRhIHRyYW5zbWlzc2lvbiBpdCBpcyB1cGRhdGVkIHRvIHRoZSBudW1iZXIgb2YKK2NoYXJhY3Rl cnMgc2VudC4KIC5TaCBSRVRVUk4gVkFMVUVTCi1UaGVzZSBjYWxscyByZXR1cm4gdGhlIG51bWJl ciBvZiBieXRlcyByZWNlaXZlZCwgb3IgLTEKLWlmIGFuIGVycm9yIG9jY3VycmVkLgorVGhlc2Ug Y2FsbHMgZXhjZXB0CisuRm4gcmVjdm1tc2cKK3JldHVybiB0aGUgbnVtYmVyIG9mIGJ5dGVzIHJl Y2VpdmVkLgorLkZuIHJlY3ZtbXNnCityZXR1cm5zIHRoZSBudW1iZXIgb2YgbWVzc2FnZXMgcmVj ZWl2ZWQuCitBIHZhbHVlIG9mIC0xIGlzIHJldHVybmVkIGlmIGFuIGVycm9yIG9jY3VycmVkLgog LlNoIEVSUk9SUwogVGhlIGNhbGxzIGZhaWwgaWY6CiAuQmwgLXRhZyAtd2lkdGggRXIKZGlmZiAt LWdpdCBhL2xpYi9saWJjL3N5cy9yZWN2bW1zZy5jIGIvbGliL2xpYmMvc3lzL3JlY3ZtbXNnLmMK bmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uNmI1MTU4YQotLS0gL2Rldi9udWxs CisrKyBiL2xpYi9saWJjL3N5cy9yZWN2bW1zZy5jCkBAIC0wLDAgKzEsNzIgQEAKKy8qCisgKiBD b3B5cmlnaHQgKGMpIDIwMTYgQm9yaXMgQXN0YXJkemhpZXYsIFNtYXJ0Y29tLUJ1bGdhcmlhIEFE CisgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2Ug aW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorICogbW9kaWZpY2F0 aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25z CisgKiBhcmUgbWV0OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3Qg cmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZShzKSwgdGhpcyBsaXN0IG9m IGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBhcworICogICAgdGhlIGZp cnN0IGxpbmVzIG9mIHRoaXMgZmlsZSB1bm1vZGlmaWVkIG90aGVyIHRoYW4gdGhlIHBvc3NpYmxl CisgKiAgICBhZGRpdGlvbiBvZiBvbmUgb3IgbW9yZSBjb3B5cmlnaHQgbm90aWNlcy4KKyAqIDIu IFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUg Y29weXJpZ2h0CisgKiAgICBub3RpY2UocyksIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0 aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4KKyAqICAgIHRoZSBkb2N1bWVudGF0aW9uIGFuZC9v ciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUKKyAqICAgIGRpc3RyaWJ1dGlvbi4K KyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBDT1BZUklHSFQgSE9MREVS KFMpIGBgQVMgSVMnJyBBTkQgQU5ZCisgKiBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywg SU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQorICogSU1QTElFRCBXQVJSQU5USUVT IE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSCisgKiBQVVJQ T1NFIEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIENPUFlSSUdIVCBIT0xE RVIoUykgQkUKKyAqIExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUws IFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IKKyAqIENPTlNFUVVFTlRJQUwgREFNQUdFUyAoSU5DTFVE SU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GCisgKiBTVUJTVElUVVRFIEdP T0RTIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IKKyAqIEJV U0lORVNTIElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0Yg TElBQklMSVRZLAorICogV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUIExJQUJJTElUWSwgT1Ig VE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UKKyAqIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBB TlkgV0FZIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsCisgKiBFVkVOIElGIEFEVklT RUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgorICovCisKKyNpbmNsdWRlIDxz eXMvY2RlZnMuaD4KK19fRkJTRElEKCIkRnJlZUJTRCQiKTsKKworI2luY2x1ZGUgPGVycm5vLmg+ CisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5jbHVkZSA8c3lzL3N5c2NhbGwuaD4KKyNpbmNs dWRlIDxzeXMvc29ja2V0Lmg+CisjaW5jbHVkZSA8cHRocmVhZC5oPgorI2luY2x1ZGUgImxpYmNf cHJpdmF0ZS5oIgorCisjZGVmaW5lIFZMRU5fTUFYIDEwMjQKKworaW50CityZWN2bW1zZyhpbnQg cywgc3RydWN0IG1tc2doZHIgKm1zZ3ZlYywgdW5zaWduZWQgaW50IHZsZW4sIGludCBmbGFncykK K3sKKwlpbnQgaSwgcmV0LCByY3ZkOworCisJaWYgKHZsZW4gPiBWTEVOX01BWCkKKwkJdmxlbiA9 IFZMRU5fTUFYOworCisJcmN2ZCA9IDA7CisJZm9yIChpID0gMDsgaSA8IHZsZW47IGkrKykgewor CQllcnJubyA9IDA7CisJCXJldCA9IF9fc3lzX3JlY3Ztc2cocywgJm1zZ3ZlY1tpXS5tc2dfaGRy LCBmbGFncyk7CisJCWlmIChyZXQgPCAwIHx8IGVycm5vICE9IDApIHsKKwkJCWlmIChyY3ZkICE9 IDApIHsKKwkJCQkvKiBXZSd2ZSByZWNlaXZlZCBtZXNzYWdlcy4gTGV0IGNhbGxlciBrbm93LiAq LworCQkJCWVycm5vID0gMDsKKwkJCQlyZXR1cm4gKHJjdmQpOworCQkJfQorCQkJcmV0dXJuICgt MSk7CisJCX0KKworCQkvKiBTYXZlIHJlY2VpdmVkIGJ5dGVzICovCisJCW1zZ3ZlY1tpXS5tc2df bGVuID0gcmV0OworCisJCXJjdmQrKzsKKwl9CisKKwlyZXR1cm4gKHJjdmQpOworfQorCisjdW5k ZWYgVkxFTl9NQVgKZGlmZiAtLWdpdCBhL2xpYi9saWJjL3N5cy9zZW5kLjIgYi9saWIvbGliYy9z eXMvc2VuZC4yCmluZGV4IDhmYTJjNjQuLjZjMTRhNjAgMTAwNjQ0Ci0tLSBhL2xpYi9saWJjL3N5 cy9zZW5kLjIKKysrIGIvbGliL2xpYmMvc3lzL3NlbmQuMgpAQCAtMzQsOCArMzQsOSBAQAogLlNo IE5BTUUKIC5ObSBzZW5kICwKIC5ObSBzZW5kdG8gLAotLk5tIHNlbmRtc2cKLS5OZCBzZW5kIGEg bWVzc2FnZSBmcm9tIGEgc29ja2V0CisuTm0gc2VuZG1zZyAsCisuTm0gc2VuZG1tc2cKKy5OZCBz ZW5kIG1lc3NhZ2UocykgZnJvbSBhIHNvY2tldAogLlNoIExJQlJBUlkKIC5MYiBsaWJjCiAuU2gg U1lOT1BTSVMKQEAgLTQ3LDYgKzQ4LDggQEAKIC5GbiBzZW5kdG8gImludCBzIiAiY29uc3Qgdm9p ZCAqbXNnIiAic2l6ZV90IGxlbiIgImludCBmbGFncyIgImNvbnN0IHN0cnVjdCBzb2NrYWRkciAq dG8iICJzb2NrbGVuX3QgdG9sZW4iCiAuRnQgc3NpemVfdAogLkZuIHNlbmRtc2cgImludCBzIiAi Y29uc3Qgc3RydWN0IG1zZ2hkciAqbXNnIiAiaW50IGZsYWdzIgorLkZ0IGludAorLkZuIHNlbmRt bXNnICJpbnQgcyIgInN0cnVjdCBtbXNnaGRyICptc2d2ZWMiICJpbnQgdmxlbiIgImludCBmbGFn cyIKIC5TaCBERVNDUklQVElPTgogVGhlCiAuRm4gc2VuZApAQCAtNTUsOCArNTgsMTAgQEAgYW5k CiAuRm4gc2VuZHRvCiBhbmQKIC5GbiBzZW5kbXNnCithbmQKKy5GbiBzZW5kbW1zZwogc3lzdGVt IGNhbGxzCi1hcmUgdXNlZCB0byB0cmFuc21pdCBhIG1lc3NhZ2UgdG8gYW5vdGhlciBzb2NrZXQu CithcmUgdXNlZCB0byB0cmFuc21pdCBvbmUgb3IgbXVsdGlwbGUgbWVzc2FnZXMgKHdpdGggdGhl IGxhdHRlciBjYWxsKSB0byBhbm90aGVyIHNvY2tldC4KIFRoZQogLkZuIHNlbmQKIGZ1bmN0aW9u CkBAIC02Niw2ICs3MSw4IEBAIHN0YXRlLCB3aGlsZQogLkZuIHNlbmR0bwogYW5kCiAuRm4gc2Vu ZG1zZworYW5kCisuRm4gc2VuZG1tc2cKIG1heSBiZSB1c2VkIGF0IGFueSB0aW1lLgogLlBwCiBU aGUgYWRkcmVzcyBvZiB0aGUgdGFyZ2V0IGlzIGdpdmVuIGJ5CkBAIC04MSw2ICs4OCwxOCBAQCB1 bmRlcmx5aW5nIHByb3RvY29sLCB0aGUgZXJyb3IKIGlzIHJldHVybmVkLCBhbmQKIHRoZSBtZXNz YWdlIGlzIG5vdCB0cmFuc21pdHRlZC4KIC5QcAorVGhlCisuRm4gc2VuZG1tc2cKK2Z1bmN0aW9u IHNlbmRzIG11bHRpcGxlIG1lc3NhZ2VzIGF0IGEgY2FsbC4KK1RoZXkgYXJlIGdpdmVuIGJ5IHRo ZQorLkZhIG1zZ3ZlYwordmVjdG9yIGFsb25nIHdpdGgKKy5GYSB2bGVuCitzcGVjaWZ5aW5nIGl0 cyBzaXplIChsaW1pdGVkIHRvIDEwMjQpLiBUaGUgbnVtYmVyIG9mCitjaGFyYWN0ZXJzIHNlbnQg cGVyIGVhY2ggbWVzc2FnZSBpcyBwbGFjZWQgaW4gdGhlCisuRmEgbXNnX2xlbgorZmllbGQgb2Yg ZWFjaCBlbGVtZW50IG9mIHRoZSB2ZWN0b3IgYWZ0ZXIgdHJhbnNtaXNzaW9uLgorLlBwCiBObyBp bmRpY2F0aW9uIG9mIGZhaWx1cmUgdG8gZGVsaXZlciBpcyBpbXBsaWNpdCBpbiBhCiAuRm4gc2Vu ZCAuCiBMb2NhbGx5IGRldGVjdGVkIGVycm9ycyBhcmUgaW5kaWNhdGVkIGJ5IGEgcmV0dXJuIHZh bHVlIG9mIC0xLgpAQCAtMTM4LDEwICsxNTcsMTYgQEAgU2VlCiAuWHIgcmVjdiAyCiBmb3IgYSBk ZXNjcmlwdGlvbiBvZiB0aGUKIC5GYSBtc2doZHIKK3N0cnVjdHVyZSBhbmQgdGhlCisuRmEgbW1z Z2hkcgogc3RydWN0dXJlLgogLlNoIFJFVFVSTiBWQUxVRVMKLVRoZSBjYWxsIHJldHVybnMgdGhl IG51bWJlciBvZiBjaGFyYWN0ZXJzIHNlbnQsIG9yIC0xCi1pZiBhbiBlcnJvciBvY2N1cnJlZC4K K0FsbCBjYWxscyBleGNlcHQKKy5GbiBzZW5kbW1zZworcmV0dXJuIHRoZSBudW1iZXIgb2YgY2hh cmFjdGVycyBzZW50LiBUaGUKKy5GbiBzZW5kbW1zZworY2FsbCByZXR1cm5zIHRoZSBudW1iZXIg b2YgbWVzc2FnZXMgc2VudC4KK0lmIGFuIGVycm9yIG9jY3VycmVkIGEgdmFsdWUgb2YgLTEgaXMg cmV0dXJuZWQuCiAuU2ggRVJST1JTCiBUaGUKIC5GbiBzZW5kCkBAIC0xNDksNiArMTc0LDggQEAg ZnVuY3Rpb24gYW5kCiAuRm4gc2VuZHRvCiBhbmQKIC5GbiBzZW5kbXNnCithbmQKKy5GbiBzZW5k bW1zZwogc3lzdGVtIGNhbGxzCiBmYWlsIGlmOgogLkJsIC10YWcgLXdpZHRoIEVyCmRpZmYgLS1n aXQgYS9saWIvbGliYy9zeXMvc2VuZG1tc2cuYyBiL2xpYi9saWJjL3N5cy9zZW5kbW1zZy5jCm5l dyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjNiOTBiOTAKLS0tIC9kZXYvbnVsbAor KysgYi9saWIvbGliYy9zeXMvc2VuZG1tc2cuYwpAQCAtMCwwICsxLDcyIEBACisvKgorICogQ29w eXJpZ2h0IChjKSAyMDE2IEJvcmlzIEFzdGFyZHpoaWV2LCBTbWFydGNvbS1CdWxnYXJpYSBBRAor ICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGlu IHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlv biwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucwor ICogYXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJl dGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UocyksIHRoaXMgbGlzdCBvZiBj b25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgYXMKKyAqICAgIHRoZSBmaXJz dCBsaW5lcyBvZiB0aGlzIGZpbGUgdW5tb2RpZmllZCBvdGhlciB0aGFuIHRoZSBwb3NzaWJsZQor ICogICAgYWRkaXRpb24gb2Ygb25lIG9yIG1vcmUgY29weXJpZ2h0IG5vdGljZXMuCisgKiAyLiBS ZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNv cHlyaWdodAorICogICAgbm90aWNlKHMpLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhl IGZvbGxvd2luZyBkaXNjbGFpbWVyIGluCisgKiAgICB0aGUgZG9jdW1lbnRhdGlvbiBhbmQvb3Ig b3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlCisgKiAgICBkaXN0cmlidXRpb24uCisg KgorICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQ09QWVJJR0hUIEhPTERFUihT KSBgYEFTIElTJycgQU5EIEFOWQorICogRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElO Q0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBP RiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUgorICogUFVSUE9T RSBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBDT1BZUklHSFQgSE9MREVS KFMpIEJFCisgKiBMSUFCTEUgRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBT UEVDSUFMLCBFWEVNUExBUlksIE9SCisgKiBDT05TRVFVRU5USUFMIERBTUFHRVMgKElOQ0xVRElO RywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRgorICogU1VCU1RJVFVURSBHT09E UyBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SCisgKiBCVVNJ TkVTUyBJTlRFUlJVUFRJT04pIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJ QUJJTElUWSwKKyAqIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJVFksIE9SIFRP UlQgKElOQ0xVRElORyBORUdMSUdFTkNFCisgKiBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5Z IFdBWSBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLAorICogRVZFTiBJRiBBRFZJU0VE IE9GIFRIRSBQT1NTSUJJTElUWSBPRiBTVUNIIERBTUFHRS4KKyAqLworCisjaW5jbHVkZSA8c3lz L2NkZWZzLmg+CitfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CisKKyNpbmNsdWRlIDxlcnJuby5oPgor I2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5cy9zeXNjYWxsLmg+CisjaW5jbHVk ZSA8c3lzL3NvY2tldC5oPgorI2luY2x1ZGUgPHB0aHJlYWQuaD4KKyNpbmNsdWRlICJsaWJjX3By aXZhdGUuaCIKKworI2RlZmluZSBWTEVOX01BWCAxMDI0CisKK2ludAorc2VuZG1tc2coaW50IHMs IHN0cnVjdCBtbXNnaGRyICptc2d2ZWMsIHVuc2lnbmVkIGludCB2bGVuLCBpbnQgZmxhZ3MpCit7 CisJaW50IGksIHJldCwgc2VudDsKKworCWlmICh2bGVuID4gVkxFTl9NQVgpCisJCXZsZW4gPSBW TEVOX01BWDsKKworCXNlbnQgPSAwOworCWZvciAoaSA9IDA7IGkgPCB2bGVuOyBpKyspIHsKKwkJ ZXJybm8gPSAwOworCQlyZXQgPSBfX3N5c19zZW5kbXNnKHMsICZtc2d2ZWNbaV0ubXNnX2hkciwg ZmxhZ3MpOworCQlpZiAocmV0IDwgMCB8fCBlcnJubyAhPSAwKSB7CisJCQlpZiAoc2VudCAhPSAw KSB7CisJCQkJLyogV2UgaGF2ZSBzZW50IG1lc3NhZ2VzLiBMZXQgY2FsbGVyIGtub3cuICovCisJ CQkJZXJybm8gPSAwOworCQkJCXJldHVybiAoc2VudCk7CisJCQl9CisJCQlyZXR1cm4gKC0xKTsK KwkJfQorCisJCS8qIFNhdmUgc2VudCBieXRlcyAqLworCQltc2d2ZWNbaV0ubXNnX2xlbiA9IHJl dDsKKworCQlzZW50Kys7CisJfQorCisJcmV0dXJuIChzZW50KTsKK30KKworI3VuZGVmIFZMRU5f TUFYCmRpZmYgLS1naXQgYS9zeXMvc3lzL3NvY2tldC5oIGIvc3lzL3N5cy9zb2NrZXQuaAppbmRl eCAxOGUyZGUxLi5mNzBkY2VkIDEwMDY0NAotLS0gYS9zeXMvc3lzL3NvY2tldC5oCisrKyBiL3N5 cy9zeXMvc29ja2V0LmgKQEAgLTU5NSw2ICs1OTUsMTggQEAgc3RydWN0IHNmX2hkdHIgewogI2Vu ZGlmIC8qIF9LRVJORUwgKi8KICNlbmRpZiAvKiBfX0JTRF9WSVNJQkxFICovCiAKKyNpZm5kZWYg X0tFUk5FTAorI2lmZGVmIF9fQlNEX1ZJU0lCTEUKKy8qCisgKiBTZW5kL3JlY3ZtbXNnIHNwZWNp ZmljIHN0cnVjdHVyZShzKQorICovCitzdHJ1Y3QgbW1zZ2hkciB7CisJc3RydWN0IG1zZ2hkcglt c2dfaGRyOwkJLyogbWVzc2FnZSBoZWFkZXIgKi8KKwl1bnNpZ25lZCBpbnQJbXNnX2xlbjsJCS8q IG1lc3NhZ2UgbGVuZ3RoICovCit9OworI2VuZGlmIC8qIF9fQlNEX1ZJU0lCTEUgKi8KKyNlbmRp ZiAvKiAhX0tFUk5FTCAqLworCiAjaWZuZGVmCV9LRVJORUwKIAogI2luY2x1ZGUgPHN5cy9jZGVm cy5oPgpAQCAtNjE1LDExICs2MjcsMTcgQEAgaW50CWxpc3RlbihpbnQsIGludCk7CiBzc2l6ZV90 CXJlY3YoaW50LCB2b2lkICosIHNpemVfdCwgaW50KTsKIHNzaXplX3QJcmVjdmZyb20oaW50LCB2 b2lkICosIHNpemVfdCwgaW50LCBzdHJ1Y3Qgc29ja2FkZHIgKiBfX3Jlc3RyaWN0LCBzb2NrbGVu X3QgKiBfX3Jlc3RyaWN0KTsKIHNzaXplX3QJcmVjdm1zZyhpbnQsIHN0cnVjdCBtc2doZHIgKiwg aW50KTsKKyNpZiBfX0JTRF9WSVNJQkxFCitpbnQJcmVjdm1tc2coaW50LCBzdHJ1Y3QgbW1zZ2hk ciAqLCB1bnNpZ25lZCBpbnQsIGludCk7CisjZW5kaWYKIHNzaXplX3QJc2VuZChpbnQsIGNvbnN0 IHZvaWQgKiwgc2l6ZV90LCBpbnQpOwogc3NpemVfdAlzZW5kdG8oaW50LCBjb25zdCB2b2lkICos CiAJICAgIHNpemVfdCwgaW50LCBjb25zdCBzdHJ1Y3Qgc29ja2FkZHIgKiwgc29ja2xlbl90KTsK IHNzaXplX3QJc2VuZG1zZyhpbnQsIGNvbnN0IHN0cnVjdCBtc2doZHIgKiwgaW50KTsKICNpZiBf X0JTRF9WSVNJQkxFCitpbnQJc2VuZG1tc2coaW50LCBzdHJ1Y3QgbW1zZ2hkciAqLCB1bnNpZ25l ZCBpbnQsIGludCk7CisjZW5kaWYKKyNpZiBfX0JTRF9WSVNJQkxFCiBpbnQJc2VuZGZpbGUoaW50 LCBpbnQsIG9mZl90LCBzaXplX3QsIHN0cnVjdCBzZl9oZHRyICosIG9mZl90ICosIGludCk7CiBp bnQJc2V0ZmliKGludCk7CiAjZW5kaWYK --001a114b3ebc6c912e0529ae96fb-- From owner-freebsd-threads@freebsd.org Tue Jan 19 22:00:53 2016 Return-Path: Delivered-To: freebsd-threads@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 9392DA895B9 for ; Tue, 19 Jan 2016 22:00:53 +0000 (UTC) (envelope-from jilles@stack.nl) 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 801981F92 for ; Tue, 19 Jan 2016 22:00:53 +0000 (UTC) (envelope-from jilles@stack.nl) Received: by mailman.ysv.freebsd.org (Postfix) id 6B79EA895B6; Tue, 19 Jan 2016 22:00:53 +0000 (UTC) Delivered-To: threads@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 6AE6EA895B5; Tue, 19 Jan 2016 22:00:53 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 364741F8E; Tue, 19 Jan 2016 22:00:53 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 9B1AFB8059; Tue, 19 Jan 2016 23:00:49 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 86B1828494; Tue, 19 Jan 2016 23:00:49 +0100 (CET) Date: Tue, 19 Jan 2016 23:00:49 +0100 From: Jilles Tjoelker To: Boris Astardzhiev Cc: Konstantin Belousov , net@freebsd.org, threads@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160119220049.GA56408@stack.nl> References: <20160113080349.GC72455@kib.kiev.ua> <20160116195657.GJ3942@kib.kiev.ua> <20160116202534.GK3942@kib.kiev.ua> <20160117211853.GA37847@stack.nl> <20160118044826.GS3942@kib.kiev.ua> <20160118140811.GW3942@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 22:00:53 -0000 On Tue, Jan 19, 2016 at 01:58:27PM +0200, Boris Astardzhiev wrote: > I removed the pthread_testcancel() calls and cut the interposing > stuff from my patch as suggested. I extended the send/recv(2) manpages > regarding > the mm calls. Comments and suggestions? > [snip] > diff --git a/lib/libc/sys/Symbol.map b/lib/libc/sys/Symbol.map > index 7b3257c..724e1b4 100644 > --- a/lib/libc/sys/Symbol.map > +++ b/lib/libc/sys/Symbol.map > @@ -399,6 +399,8 @@ FBSD_1.4 { > utimensat; > numa_setaffinity; > numa_getaffinity; > + sendmmsg; > + recvmmsg; > }; OK. > > FBSDprivate_1.0 { > @@ -1051,4 +1053,6 @@ FBSDprivate_1.0 { > gssd_syscall; > __libc_interposing_slot; > __libc_sigwait; > + _sendmmsg; > + _recvmmsg; > }; The _ versions need not be exported. Not exporting reduces code size and improves performance. > diff --git a/lib/libc/sys/recv.2 b/lib/libc/sys/recv.2 > index 326e7ff..81a0201 100644 > --- a/lib/libc/sys/recv.2 > +++ b/lib/libc/sys/recv.2 > [snip] I think the recv.2 and send.2 man pages are long enough as they are, and separate recvmmsg.3 and sendmmsg.3 pages will be clearer. This is also because recvmmsg/sendmmsg can be ignored when performance is good enough without them. This differs from what Konstantin thinks. > diff --git a/lib/libc/sys/recvmmsg.c b/lib/libc/sys/recvmmsg.c > new file mode 100644 > index 0000000..6b5158a > --- /dev/null > +++ b/lib/libc/sys/recvmmsg.c > @@ -0,0 +1,72 @@ > [snip] > +int > +recvmmsg(int s, struct mmsghdr *msgvec, unsigned int vlen, int flags) > +{ The Linux version has an additional parameter struct timespec *timeout (but only for recvmmsg, not for 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 From owner-freebsd-threads@freebsd.org Wed Jan 20 07:32:01 2016 Return-Path: Delivered-To: freebsd-threads@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 70D6FA8944F for ; Wed, 20 Jan 2016 07:32:01 +0000 (UTC) (envelope-from kostikbel@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 57BC715BB for ; Wed, 20 Jan 2016 07:32:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5502CA8944D; Wed, 20 Jan 2016 07:32:01 +0000 (UTC) Delivered-To: threads@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 547ADA8944B; Wed, 20 Jan 2016 07:32:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C6D6C15B5; Wed, 20 Jan 2016 07:32:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u0K7VtTp043835 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 20 Jan 2016 09:31:55 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u0K7VtTp043835 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u0K7VtE8043834; Wed, 20 Jan 2016 09:31:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Jan 2016 09:31:55 +0200 From: Konstantin Belousov To: Boris Astardzhiev Cc: Jilles Tjoelker , net@freebsd.org, threads@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160120073154.GB3942@kib.kiev.ua> References: <20160113080349.GC72455@kib.kiev.ua> <20160116195657.GJ3942@kib.kiev.ua> <20160116202534.GK3942@kib.kiev.ua> <20160117211853.GA37847@stack.nl> <20160118044826.GS3942@kib.kiev.ua> <20160118140811.GW3942@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 07:32:01 -0000 On Tue, Jan 19, 2016 at 01:58:27PM +0200, Boris Astardzhiev wrote: > +int > +recvmmsg(int s, struct mmsghdr *msgvec, unsigned int vlen, int flags) > +{ > + int i, ret, rcvd; Shouldn't i and rcvd be unsigned as well ? Shouldn't return value also be unsigned ? > + > + if (vlen > VLEN_MAX) > + vlen = VLEN_MAX; Why is this restriction needed ? > + > + rcvd = 0; > + for (i = 0; i < vlen; i++) { > + errno = 0; > + ret = __sys_recvmsg(s, &msgvec[i].msg_hdr, flags); > + if (ret < 0 || errno != 0) { I do not see why do you need to clear errno before, and then do this test. Just check ret == -1, in which case errno was set from the immediate syscall. > + if (rcvd != 0) { > + /* We've received messages. Let caller know. */ > + errno = 0; This cleaning is not needed as well. For successfull functions returns, errno value is undefined. > + return (rcvd); > + } > + return (-1); > + } > + > + /* Save received bytes */ > + msgvec[i].msg_len = ret; > + Extra empty line. > + rcvd++; > + } > + > + return (rcvd); > +} From owner-freebsd-threads@freebsd.org Wed Jan 20 08:29:50 2016 Return-Path: Delivered-To: freebsd-threads@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 82692A8896B for ; Wed, 20 Jan 2016 08:29:50 +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 5F4551E39 for ; Wed, 20 Jan 2016 08:29:50 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5E98AA8896A; Wed, 20 Jan 2016 08:29:50 +0000 (UTC) Delivered-To: threads@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 440DEA88968; Wed, 20 Jan 2016 08:29:50 +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 C4A841E38; Wed, 20 Jan 2016 08:29:49 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id l65so168946761wmf.1; Wed, 20 Jan 2016 00:29:49 -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=+vTDR6o5a+4Vpe7UStvzcqXSbAADfj4yw89x0DnoWgA=; b=sGAOiMjRI6vo85cKo2Kj5Lhhy6oKMdSGRZM30DGLX5wifwlwCrJ6/BxhePBuQApvNz R8lgSFMVj0+C5I6kmhN8m/1PnWcOWiwk92BZfudeSWnLyursnXFSh0iVLUQmhXbCmEGt HPpIGjt+TJHkBb9E8YB1kYWB6jFqK9XcnwtUBmdjCLYAV9DVUgFuUt7+zcDkTAYj5v5h +7wbw+BjLfWFAfKdxOucv8Pm8si6VdDhOtX+OcdC1uZ51GDwhjbWel0slMBqPkfSoclh Fxf+TBBfr9xQu8EJjsCNDOSy97Tyw9wizwqOgMtTTcU/X37FzGTkuhj8Mq8Krm1s023A fkEg== 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=+vTDR6o5a+4Vpe7UStvzcqXSbAADfj4yw89x0DnoWgA=; b=LCkaoWd21uG2ICHyMwxn0NPtIuAjNwu22BkymWa65x9ccmwyVJNReki+CwNnY9RgkG 0GdBMdRoZ7s4UdQFEjdWvAssx4ikjF3DnliZE2Z6tF1KbW1CcOA3t2gP5DKJ+PZcaj2u Yla6oWNJusaCqndqaWFwDfscoPPZytBBsCUDK1dwI8tpKJZE2t46UCm/n22NdR/U6D6/ 6/KpkVxlxJRxegoThdr+4hUWIK8W75IVOjFHcI0GJp3lLAgwWhU7JgU/5+7kZIBPD55F 4zEvusKV2erak1AtrdlYOIgQw/OHXdWALOVttq5qqemw5tQ2UUNRCeMJ64VOoYw7/ntF GkWA== X-Gm-Message-State: AG10YORiKsUqT7/oQ1+Brt8KV+D4XOAoqsDWEPX2P8dZQCyEFYjH9O7q9A3TZ09nfuFVNFpX29UsfXZxGgzwPw== MIME-Version: 1.0 X-Received: by 10.28.16.8 with SMTP id 8mr2643914wmq.77.1453278587459; Wed, 20 Jan 2016 00:29:47 -0800 (PST) Received: by 10.28.136.148 with HTTP; Wed, 20 Jan 2016 00:29:47 -0800 (PST) In-Reply-To: <20160120073154.GB3942@kib.kiev.ua> References: <20160113080349.GC72455@kib.kiev.ua> <20160116195657.GJ3942@kib.kiev.ua> <20160116202534.GK3942@kib.kiev.ua> <20160117211853.GA37847@stack.nl> <20160118044826.GS3942@kib.kiev.ua> <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> Date: Wed, 20 Jan 2016 10:29:47 +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-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 08:29:50 -0000 jt>> jt>> FBSDprivate_1.0 { jt>> @@ -1051,4 +1053,6 @@ FBSDprivate_1.0 { jt>> gssd_syscall; jt>> __libc_interposing_slot; jt>> __libc_sigwait; jt>> + _sendmmsg; jt>> + _recvmmsg; jt>> }; jt> jt>The _ versions need not be exported. Not exporting reduces code size and jt>improves performance. I'll fix it. jt>> diff --git a/lib/libc/sys/recv.2 b/lib/libc/sys/recv.2 jt>> index 326e7ff..81a0201 100644 jt>> --- a/lib/libc/sys/recv.2 jt>> +++ b/lib/libc/sys/recv.2 jt>> [snip] jt> jt>I think the recv.2 and send.2 man pages are long enough as they are, and jt>separate recvmmsg.3 and sendmmsg.3 pages will be clearer. This is also jt>because recvmmsg/sendmmsg can be ignored when performance is good enough jt>without them. This differs from what Konstantin thinks. md>If they are to be made separate man pages can I suggest that the md>recv/send(2) manpages be changes to at least make early reference to md>the *mmsg() calls? md> md>Purely as marketing. My perception is that awareness of the *mmsg() md>calls is rather limited. Let me know the final decision then - whether in the existing manpages or in new files. jt>The Linux version has an additional parameter struct timespec *timeout jt>(but only for recvmmsg, not for sendmmsg). Note that implementing this jt>in a Linux-compatible manner has low overhead, since Linux only checks jt>it between packets and never interrupts a wait because of this timeout jt>(source: http://man7.org/linux/man-pages/man2/recvmmsg.2.html ). That's right. Shall I try to implement the timeout part or leave it the way it is now? kb>Shouldn't i and rcvd be unsigned as well ? Shouldn't return value kb>also be unsigned ? I think i and rcvd should be unsigned whereas ret should not - after all if an error occurred we get -1. kb>> + kb>> + if (vlen > VLEN_MAX) kb>> + vlen = VLEN_MAX; kb>Why is this restriction needed ? Not needed. I'll remove it. kb>> + kb>> + rcvd = 0; kb>> + for (i = 0; i < vlen; i++) { kb>> + errno = 0; kb>> + ret = __sys_recvmsg(s, &msgvec[i].msg_hdr, flags); kb>> + if (ret < 0 || errno != 0) { kb>I do not see why do you need to clear errno before, and then do this test. kb>Just check ret == -1, in which case errno was set from the immediate syscall. kb> kb>> + if (rcvd != 0) { kb>> + /* We've received messages. Let caller know. */ kb>> + errno = 0; kb>This cleaning is not needed as well. For successfull functions returns, kb>errno value is undefined. Wouldn't I confuse apps if they check errno in the follow case - I want to receive two messages. The first __sys_recvmsg succeeds and then for the second __sys_recvmsg fails. Thus errno will be != 0 and I'm telling the app that I have received one message by returning 1 but errno will be != 0. Is this correct? Regards, Boris Astardzhiev On Wed, Jan 20, 2016 at 9:31 AM, Konstantin Belousov wrote: > On Tue, Jan 19, 2016 at 01:58:27PM +0200, Boris Astardzhiev wrote: > > +int > > +recvmmsg(int s, struct mmsghdr *msgvec, unsigned int vlen, int flags) > > +{ > > + int i, ret, rcvd; > Shouldn't i and rcvd be unsigned as well ? Shouldn't return value > also be unsigned ? > > + > > + if (vlen > VLEN_MAX) > > + vlen = VLEN_MAX; > Why is this restriction needed ? > > > + > > + rcvd = 0; > > + for (i = 0; i < vlen; i++) { > > + errno = 0; > > + ret = __sys_recvmsg(s, &msgvec[i].msg_hdr, flags); > > + if (ret < 0 || errno != 0) { > I do not see why do you need to clear errno before, and then do this test. > Just check ret == -1, in which case errno was set from the immediate > syscall. > > > + if (rcvd != 0) { > > + /* We've received messages. Let caller > know. */ > > + errno = 0; > This cleaning is not needed as well. For successfull functions returns, > errno value is undefined. > > > + return (rcvd); > > + } > > + return (-1); > > + } > > + > > + /* Save received bytes */ > > + msgvec[i].msg_len = ret; > > + > Extra empty line. > > + rcvd++; > > + } > > + > > + return (rcvd); > > +} > From owner-freebsd-threads@freebsd.org Wed Jan 20 10:30:56 2016 Return-Path: Delivered-To: freebsd-threads@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 A8D2FA89680 for ; Wed, 20 Jan 2016 10:30:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) 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 927A21D93 for ; Wed, 20 Jan 2016 10:30:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id 91AB3A8967E; Wed, 20 Jan 2016 10:30:56 +0000 (UTC) Delivered-To: threads@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 9121CA8967D; Wed, 20 Jan 2016 10:30:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 58AEE1D92; Wed, 20 Jan 2016 10:30:55 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id CF54910471B6; Wed, 20 Jan 2016 21:30:45 +1100 (AEDT) Date: Wed, 20 Jan 2016 21:30:44 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov cc: Boris Astardzhiev , threads@freebsd.org, Jilles Tjoelker , net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? In-Reply-To: <20160120073154.GB3942@kib.kiev.ua> Message-ID: <20160120205544.Q2305@besplex.bde.org> References: <20160113080349.GC72455@kib.kiev.ua> <20160116195657.GJ3942@kib.kiev.ua> <20160116202534.GK3942@kib.kiev.ua> <20160117211853.GA37847@stack.nl> <20160118044826.GS3942@kib.kiev.ua> <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=R4L+YolX c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=JzwRw_2MAAAA:8 a=kj9zAlcOel0A:10 a=FZoMsACIJPzh2gu83OkA:9 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 10:30:56 -0000 On Wed, 20 Jan 2016, Konstantin Belousov wrote: > On Tue, Jan 19, 2016 at 01:58:27PM +0200, Boris Astardzhiev wrote: >> +int >> +recvmmsg(int s, struct mmsghdr *msgvec, unsigned int vlen, int flags) >> +{ >> + int i, ret, rcvd; > Shouldn't i and rcvd be unsigned as well ? Shouldn't return value > also be unsigned ? None of the above. Plain recvmsg() returns ssize_t and its len arg has type size_t. That is excessively typedefed and excessively large with 64-bit ssize_t, but it is silly for the multiple-message variant to use smaller types. Otherwise, all the integer types should be int. recvmsg() is still declared in syscalls.master as returning int, but it seems to be correct internallly. It is like read() and returns ssize_t in td_retval[0]. No wrong prototypes seem to be generated from the wrong retun types in syscalls.master. >> + rcvd = 0; >> + for (i = 0; i < vlen; i++) { >> + errno = 0; >> + ret = __sys_recvmsg(s, &msgvec[i].msg_hdr, flags); >> + if (ret < 0 || errno != 0) { > I do not see why do you need to clear errno before, and then do this test. > Just check ret == -1, in which case errno was set from the immediate syscall. The errno method (and not checking ret at all) is best if for syscalls that return -1 for a non-error. It is not needed here. Bruce From owner-freebsd-threads@freebsd.org Wed Jan 20 10:36:56 2016 Return-Path: Delivered-To: freebsd-threads@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 DE778A89867 for ; Wed, 20 Jan 2016 10:36:56 +0000 (UTC) (envelope-from chagin.dmitry@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 BB12410B8 for ; Wed, 20 Jan 2016 10:36:56 +0000 (UTC) (envelope-from chagin.dmitry@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id B83CFA89862; Wed, 20 Jan 2016 10:36:56 +0000 (UTC) Delivered-To: threads@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 9F1D2A89860; Wed, 20 Jan 2016 10:36:56 +0000 (UTC) (envelope-from chagin.dmitry@gmail.com) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (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 6537A10B6; Wed, 20 Jan 2016 10:36:56 +0000 (UTC) (envelope-from chagin.dmitry@gmail.com) Received: by mail-ig0-x22e.google.com with SMTP id z14so98573846igp.1; Wed, 20 Jan 2016 02:36:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=WyZEfFBDMONX4ohADRokt0i8vFA21mKNiz5jHtizpwU=; b=0ym1B6tTPv+vMlj/PBvOa0KmUiPJmBx+qP2/jAlNgFp797oyDFEwgKKsNnZuVqP9UO p1YzYAiMq9PEixz07Z44qL140wnpsuZqazcJWbtzQxp+G6CRFlsu+s1N9fit43gf/+1d pwtTh6tBQ6NfQt2C6LlvZ3SpYxxlm1GVcH4Q3I+FCDZ4/H/HbWkpVAerC8LxPyx4yMFq kSiOkUbU886tWc7rbCYqiBnTQocruIWrGl30KKSucTlI2Nhy6wvmnbAsxZ2h1fW8J7Ks uPiuiBCzmUSvMYg1sUI4ecDlE0GG3r0A0XYxnK2Hi4fm6WFLavqZ1eBv++foir16y0IY DWoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WyZEfFBDMONX4ohADRokt0i8vFA21mKNiz5jHtizpwU=; b=cIhf9rAEJcv+je7Fampm1R4qdf7Vzw+Z9T1KU4QPkcdM31Y8oQnMpWgtWR9Of/aiI3 1KGteMFB/8TpvtyqwhGaad761D0NnV8nWYEwsX1VlvDNg3tbIk3XrfxV1E8tQeQM4F+I hglD/+YPchgsbbftMisLpw1fLuSq3C7jvpMQDO5KX++YwQo1ZcyTHQR1qRU1HGOUA6S1 teRzoyl1RvTP2lODjHLXTxQF6wMSq+VtU2XPwLe+QuT4DER6Y+4xjbQ8/26QDQ4qTqvf R4laVKBql0juHlK5LKtxi0ZjdHjoN80UPAiCHbGngvlfYvRI+f5xSiOmRGYKrvKSNxvC OmGA== X-Gm-Message-State: AG10YOS0Ti5kB5pxEzI9elX1pZsxsxBFD3q4b5bH8nIaHCBd2lMBtYLXxdzJep2IRmI9n+aekBTsoHWG5Ym5eg== MIME-Version: 1.0 X-Received: by 10.50.21.10 with SMTP id r10mr2928653ige.93.1453286215854; Wed, 20 Jan 2016 02:36:55 -0800 (PST) Sender: chagin.dmitry@gmail.com Received: by 10.79.82.130 with HTTP; Wed, 20 Jan 2016 02:36:55 -0800 (PST) In-Reply-To: References: <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> <20160118140811.GW3942@kib.kiev.ua> Date: Wed, 20 Jan 2016 13:36:55 +0300 X-Google-Sender-Auth: EbHlJ9b9lzgCZi_O4I6WYJ0WkL0 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Dmitry Chagin To: Boris Astardzhiev Cc: Konstantin Belousov , threads@freebsd.org, net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 10:36:57 -0000 2016-01-19 14:58 GMT+03:00 Boris Astardzhiev : > Hello, > > I removed the pthread_testcancel() calls and cut the interposing > stuff from my patch as suggested. I extended the send/recv(2) manpages > regarding > the mm calls. Comments and suggestions? > > btw, what is the reason to not make this functions as a system call? seems that calling [xxxx]msg syscalls in a loop will be a considerable overhead From owner-freebsd-threads@freebsd.org Thu Jan 21 09:35:17 2016 Return-Path: Delivered-To: freebsd-threads@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 3E569A8920E for ; Thu, 21 Jan 2016 09:35:17 +0000 (UTC) (envelope-from kostikbel@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 236001D42 for ; Thu, 21 Jan 2016 09:35:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 1E9A9A89208; Thu, 21 Jan 2016 09:35:17 +0000 (UTC) Delivered-To: threads@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 04132A89202; Thu, 21 Jan 2016 09:35:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A2AB21D40; Thu, 21 Jan 2016 09:35:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u0L9Z99s097441 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 21 Jan 2016 11:35:09 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u0L9Z99s097441 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u0L9Z9Kr097440; Thu, 21 Jan 2016 11:35:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 21 Jan 2016 11:35:09 +0200 From: Konstantin Belousov To: Boris Astardzhiev Cc: Jilles Tjoelker , net@freebsd.org, threads@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160121093509.GK3942@kib.kiev.ua> References: <20160116195657.GJ3942@kib.kiev.ua> <20160116202534.GK3942@kib.kiev.ua> <20160117211853.GA37847@stack.nl> <20160118044826.GS3942@kib.kiev.ua> <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 09:35:17 -0000 On Wed, Jan 20, 2016 at 10:29:47AM +0200, Boris Astardzhiev wrote: > Let me know the final decision then - whether in the existing manpages or > in new files. Decide it yourself, it is your patch. If you are fine with writing new man page, I do not object. > > jt>The Linux version has an additional parameter struct timespec *timeout > jt>(but only for recvmmsg, not for sendmmsg). Note that implementing this > jt>in a Linux-compatible manner has low overhead, since Linux only checks > jt>it between packets and never interrupts a wait because of this timeout > jt>(source: http://man7.org/linux/man-pages/man2/recvmmsg.2.html ). > > That's right. Shall I try to implement the timeout part or leave > it the way it is now? I do not see any sense in making the functions with signature or semantic different from Linux version. Right now, the goal of including the patch is compatibility. > > kb>Shouldn't i and rcvd be unsigned as well ? Shouldn't return value > kb>also be unsigned ? > I think i and rcvd should be unsigned whereas ret should not - after all > if an error occurred we get -1. I looked at the real signatures and man pages for the Linux functions, finally. There is indeed the timeout arg, the MSG_WAITFORONE flag for recvmmsg(3), and Linux uses ints for what would be naturally size_t. > kb>> + > kb>> + rcvd = 0; > kb>> + for (i = 0; i < vlen; i++) { > kb>> + errno = 0; > kb>> + ret = __sys_recvmsg(s, &msgvec[i].msg_hdr, flags); > kb>> + if (ret < 0 || errno != 0) { > kb>I do not see why do you need to clear errno before, and then do this > test. > kb>Just check ret == -1, in which case errno was set from the immediate > syscall. > kb> > kb>> + if (rcvd != 0) { > kb>> + /* We've received messages. Let caller > know. */ > kb>> + errno = 0; > kb>This cleaning is not needed as well. For successfull functions returns, > kb>errno value is undefined. > > Wouldn't I confuse apps if they check errno in the follow case - I want to > receive two messages. The first __sys_recvmsg succeeds and then for the > second __sys_recvmsg fails. Thus errno will be != 0 and I'm telling the app > that I have received one message by returning 1 but errno will be != 0. > Is this correct? errno value is only defined after the function explicitely returned error. Apps which test for errno without testing for error are wrong. From owner-freebsd-threads@freebsd.org Thu Jan 21 13:27:28 2016 Return-Path: Delivered-To: freebsd-threads@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 02884A8B771 for ; Thu, 21 Jan 2016 13:27:28 +0000 (UTC) (envelope-from brde@optusnet.com.au) 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 DC05A137F for ; Thu, 21 Jan 2016 13:27:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id D8961A8B76E; Thu, 21 Jan 2016 13:27:27 +0000 (UTC) Delivered-To: threads@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 D6C41A8B76C; Thu, 21 Jan 2016 13:27:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 989F1137C; Thu, 21 Jan 2016 13:27:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id C742B1044CE3; Fri, 22 Jan 2016 00:27:14 +1100 (AEDT) Date: Fri, 22 Jan 2016 00:27:14 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov cc: Boris Astardzhiev , threads@freebsd.org, Jilles Tjoelker , net@freebsd.org Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? In-Reply-To: <20160121093509.GK3942@kib.kiev.ua> Message-ID: <20160121233040.E1864@besplex.bde.org> References: <20160116195657.GJ3942@kib.kiev.ua> <20160116202534.GK3942@kib.kiev.ua> <20160117211853.GA37847@stack.nl> <20160118044826.GS3942@kib.kiev.ua> <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=cK4dyQqN c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=JzwRw_2MAAAA:8 a=kj9zAlcOel0A:10 a=-W6hXtnpK6wFgIz_TycA:9 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 13:27:28 -0000 On Thu, 21 Jan 2016, Konstantin Belousov wrote: > On Wed, Jan 20, 2016 at 10:29:47AM +0200, Boris Astardzhiev wrote: >> kb>Shouldn't i and rcvd be unsigned as well ? Shouldn't return value >> kb>also be unsigned ? >> I think i and rcvd should be unsigned whereas ret should not - after all >> if an error occurred we get -1. > I looked at the real signatures and man pages for the Linux functions, > finally. There is indeed the timeout arg, the MSG_WAITFORONE flag for > recvmmsg(3), and Linux uses ints for what would be naturally size_t. It knows better than POSIX, so has restored the v7 types :-). Probably not intentionally. FreeBSD-1 used the v7 types for recv* in FreeBSD-1, but this was changed in 4.4BSD-Lite1. >> kb>> + rcvd = 0; >> kb>> + for (i = 0; i < vlen; i++) { >> kb>> + errno = 0; >> kb>> + ret = __sys_recvmsg(s, &msgvec[i].msg_hdr, flags); >> kb>> + if (ret < 0 || errno != 0) { >> kb>I do not see why do you need to clear errno before, and then do this >> test. >> kb>Just check ret == -1, in which case errno was set from the immediate >> syscall. >> kb> >> kb>> + if (rcvd != 0) { >> kb>> + /* We've received messages. Let caller >> know. */ >> kb>> + errno = 0; >> kb>This cleaning is not needed as well. For successfull functions returns, >> kb>errno value is undefined. >> >> Wouldn't I confuse apps if they check errno in the follow case - I want to >> receive two messages. The first __sys_recvmsg succeeds and then for the >> second __sys_recvmsg fails. Thus errno will be != 0 and I'm telling the app >> that I have received one message by returning 1 but errno will be != 0. >> Is this correct? > > errno value is only defined after the function explicitely returned error. > Apps which test for errno without testing for error are wrong. Mostly such tests find wrong implementations. Only low quality implmentations set error for non-errors. I checked some details: - both C99 and POSIX.1-2001 forbid setting errno to 0 in library functions - C99 and draft C11 explicitly say that errno may be clobbered for non-errors by functions that are not documented to set errno. It intends to also say that errno may not be clobbered for non-errors by functions are documented to set errno, but actually says nothing about this case (except in a footnote, it says "Thus [the usual method of setting errno before the call and checking it after ``should'' be used to check for errors]." Footnotes are not part of the standard, so this also says nothing. But it gives the intent. - C99 doesn't say anything specific about this for strtol. But strtol needs errno to not be set on non-error for its API. This gives the intent of the documentation for errno in the standard itself. - POSIX.1-2001 says that applications "should" only be examined when it is indicated to be valid by a function's return value. This is wrong for all functions where errno is part of the API (like strtol), and it would be inconsistent with C99 and C11 if these standards said what they intend to say, for many more functions. First, all of the C99 functions that are documented to set errno. Then, if POSIX follows the spirit of the intent of C99, then just about all POSIX functions must not clobber errno for non-errors, since (unlike in C99) just about all functions in POSIX are documented to set errno. - POSIX.1-2001 apparently agrees with me that C99 doesn't say what it intends to say. It explicitly says that strtol shall not change "t setting of" errno on success, and marks this as an extension of C99. - I couldn't find even a buggy generic clause in POSIX.1-2001 saying what C99 intends to say even for the C99 parts of POSIX. If there were such a clause, then strtol wouldn't need a special extension. This means that some other C99 functions need special clauses, and there are likely to be bugs in this since some don't really need them except to conform with C99's intentions. - not many C99 functions are specified to set errno. The main ones are the strtol family, math functions (most can set ERANGE or EDOM), and wide character functions (many can set EILSEQ). POSIX.1-2001 seems to be missing a special clause for the first wide character function that I looked at -- fputwc(). For math functions, it has special statements ad nauseum (about 20 lines per function for duplicated for 20-50 functions). Bruce From owner-freebsd-threads@freebsd.org Fri Jan 22 09:15:20 2016 Return-Path: Delivered-To: freebsd-threads@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 D88A0A8A3EF for ; Fri, 22 Jan 2016 09:15:20 +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 B34651C97 for ; Fri, 22 Jan 2016 09:15:20 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id B1213A8A3EC; Fri, 22 Jan 2016 09:15:20 +0000 (UTC) Delivered-To: threads@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 9698DA8A3EB; Fri, 22 Jan 2016 09:15:20 +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 06F7A1C96; Fri, 22 Jan 2016 09:15:20 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id u188so10684798wmu.1; Fri, 22 Jan 2016 01:15:19 -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=auR0WeQdkc1zTo965Qk2tdsr9vGRrHhKpeD3uXFHyNg=; b=rf/AYq6b4exhWxh7Tgs9TweWXRVlKc1BAfi4iBd8qHfhfdBZ7wHfW61U2HWW8Qjvca RJz7Y5+RHReXXOh8eA747cAzupR75Je+51Uzo5AqQ8OMDHrK4zUa5pJvlo8g5E/Uykck +nJIeMvJpvBgTGhiWltdR2QvbMttPGK6P2BPirPtl83LUXrth2akvPuhup4FKs68bZ3N O3MGXfJZv+FSlZX5dQvI7v6t/SheF01N8T70ChYckdOKDYEh4Xgd6Gbtf0LPKQqr0QaX e2qlkNizTucnf2E2bY6+/fR6R7UangP7Bz6t/ozkIDDV+0kJmSpq09m5B2ISZxhnm0Up 6ebQ== 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=auR0WeQdkc1zTo965Qk2tdsr9vGRrHhKpeD3uXFHyNg=; b=A9yZcRoHu2AP1ajNU7/0iLdGPb9B5GVWS1HNcD0ziCmxJdvvbe/usmPyaOkHrVY/6n O/FB8d1q0eAqhnl4c0A8+hr8ins/a6f5uMrTpmYpqNZsKsen6ZJ2ndJDAnqVaXaJd3Ht d3/9ViysVm4NK93MKsRE0j8OiEqv1bX3x7vXv1VEYgc81Pxg3NYotNqwD/HwsoNGFig+ C9NrnBKX4RCV+rwfM5l5Z58SDdyPHwXOhgT0VKsqRIuJF3dq6VU3qJDZ2Tlt/s/BbB+T eJqj05xldPpkbK16MDmJP3Uw043MSNWnuKlG+DIuY9wWXgs9E7+Tko7QtCnudVZJcjA0 Uhzg== X-Gm-Message-State: AG10YOQxTYx+B9QkRN+tNzqfVUbk3zELDxhs1PImF7DJFhyaHeVHMATWFNJURKiGiWqWilwXvkpszlzvI2Wu5w== MIME-Version: 1.0 X-Received: by 10.28.216.134 with SMTP id p128mr2156488wmg.59.1453454118400; Fri, 22 Jan 2016 01:15:18 -0800 (PST) Received: by 10.28.136.148 with HTTP; Fri, 22 Jan 2016 01:15:18 -0800 (PST) In-Reply-To: <20160121233040.E1864@besplex.bde.org> References: <20160116195657.GJ3942@kib.kiev.ua> <20160116202534.GK3942@kib.kiev.ua> <20160117211853.GA37847@stack.nl> <20160118044826.GS3942@kib.kiev.ua> <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> Date: Fri, 22 Jan 2016 11:15:18 +0200 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Boris Astardzhiev To: Bruce Evans Cc: Konstantin Belousov , threads@freebsd.org, Jilles Tjoelker , net@freebsd.org Content-Type: multipart/mixed; boundary=001a114715826cd8660529e8a863 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 09:15:21 -0000 --001a114715826cd8660529e8a863 Content-Type: text/plain; charset=UTF-8 be>None of the above. Plain recvmsg() returns ssize_t and its len arg has be>type size_t. That is excessively typedefed and excessively large with be>64-bit ssize_t, but it is silly for the multiple-message variant to use be>smaller types. be> be>Otherwise, all the integer types should be int. It seems logical. I'll convert the ret easily to ssize_t and the vector length to size_t. Now it differs from the Linux prototype but I guess it's okay. be>The errno method (and not checking ret at all) is best if for syscalls that be>return -1 for a non-error. It is not needed here. Fixing it. kb> I do not see any sense in making the functions with signature or semantic kb> different from Linux version. Right now, the goal of including the patch kb> is compatibility. Regarding recvmmsg() - I tried to implement MSG_WAITFORONE and the timeout stuff using pselect(2) due to the timespec structure. I could have used ppoll and I'm not sure which of these two is more appropriate or maybe there's another approach? Now it has timeout just as in the Linux prototype. Comments are welcomed. See patch. Best regards, Boris Astardzhiev On Thu, Jan 21, 2016 at 3:27 PM, Bruce Evans wrote: > On Thu, 21 Jan 2016, Konstantin Belousov wrote: > > On Wed, Jan 20, 2016 at 10:29:47AM +0200, Boris Astardzhiev wrote: >> > > kb>Shouldn't i and rcvd be unsigned as well ? Shouldn't return value >>> kb>also be unsigned ? >>> I think i and rcvd should be unsigned whereas ret should not - after all >>> if an error occurred we get -1. >>> >> I looked at the real signatures and man pages for the Linux functions, >> finally. There is indeed the timeout arg, the MSG_WAITFORONE flag for >> recvmmsg(3), and Linux uses ints for what would be naturally size_t. >> > > It knows better than POSIX, so has restored the v7 types :-). Probably > not intentionally. > > FreeBSD-1 used the v7 types for recv* in FreeBSD-1, but this was changed > in 4.4BSD-Lite1. > > kb>> + rcvd = 0; >>> kb>> + for (i = 0; i < vlen; i++) { >>> kb>> + errno = 0; >>> kb>> + ret = __sys_recvmsg(s, &msgvec[i].msg_hdr, flags); >>> kb>> + if (ret < 0 || errno != 0) { >>> kb>I do not see why do you need to clear errno before, and then do this >>> test. >>> kb>Just check ret == -1, in which case errno was set from the immediate >>> syscall. >>> kb> >>> kb>> + if (rcvd != 0) { >>> kb>> + /* We've received messages. Let caller >>> know. */ >>> kb>> + errno = 0; >>> kb>This cleaning is not needed as well. For successfull functions >>> returns, >>> kb>errno value is undefined. >>> >>> Wouldn't I confuse apps if they check errno in the follow case - I want >>> to >>> receive two messages. The first __sys_recvmsg succeeds and then for the >>> second __sys_recvmsg fails. Thus errno will be != 0 and I'm telling the >>> app >>> that I have received one message by returning 1 but errno will be != 0. >>> Is this correct? >>> >> >> errno value is only defined after the function explicitely returned error. >> Apps which test for errno without testing for error are wrong. >> > > Mostly such tests find wrong implementations. Only low quality > implmentations set error for non-errors. > > I checked some details: > > - both C99 and POSIX.1-2001 forbid setting errno to 0 in library functions > > - C99 and draft C11 explicitly say that errno may be clobbered for > non-errors by functions that are not documented to set errno. It > intends to also say that errno may not be clobbered for non-errors by > functions are documented to set errno, but actually says nothing > about this case (except in a footnote, it says "Thus [the usual > method of setting errno before the call and checking it after > ``should'' be used to check for errors]." Footnotes are not part > of the standard, so this also says nothing. But it gives the intent. > > - C99 doesn't say anything specific about this for strtol. But strtol > needs errno to not be set on non-error for its API. This gives the > intent of the documentation for errno in the standard itself. > > - POSIX.1-2001 says that applications "should" only be examined when it is > indicated to be valid by a function's return value. This is wrong for > all functions where errno is part of the API (like strtol), and it > would be inconsistent with C99 and C11 if these standards said what they > intend to say, for many more functions. First, all of the C99 functions > that are documented to set errno. Then, if POSIX follows the spirit of > the intent of C99, then just about all POSIX functions must not clobber > errno for non-errors, since (unlike in C99) just about all functions in > POSIX are documented to set errno. > > - POSIX.1-2001 apparently agrees with me that C99 doesn't say what it > intends to say. It explicitly says that strtol shall not change "t > setting of" errno on success, and marks this as an extension of C99. > > - I couldn't find even a buggy generic clause in POSIX.1-2001 saying > what C99 intends to say even for the C99 parts of POSIX. If there > were such a clause, then strtol wouldn't need a special extension. > This means that some other C99 functions need special clauses, and > there are likely to be bugs in this since some don't really need > them except to conform with C99's intentions. > > - not many C99 functions are specified to set errno. The main ones > are the strtol family, math functions (most can set ERANGE or EDOM), > and wide character functions (many can set EILSEQ). POSIX.1-2001 > seems to be missing a special clause for the first wide character > function that I looked at -- fputwc(). For math functions, it has > special statements ad nauseum (about 20 lines per function for > duplicated for 20-50 functions). > > Bruce > --001a114715826cd8660529e8a863 Content-Type: text/plain; charset=US-ASCII; name="sendrecvmmsg-libconly4.diff" Content-Disposition: attachment; filename="sendrecvmmsg-libconly4.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ijpgx4140 ZGlmZiAtLWdpdCBhL2xpYi9saWJjL2luY2x1ZGUvbmFtZXNwYWNlLmggYi9saWIvbGliYy9pbmNs dWRlL25hbWVzcGFjZS5oCmluZGV4IDczOWQ3YjEuLmM5NTgyOWUgMTAwNjQ0Ci0tLSBhL2xpYi9s aWJjL2luY2x1ZGUvbmFtZXNwYWNlLmgKKysrIGIvbGliL2xpYmMvaW5jbHVkZS9uYW1lc3BhY2Uu aApAQCAtMjA4LDYgKzIwOCw3IEBACiAjZGVmaW5lCQlyZWFkdgkJCQlfcmVhZHYKICNkZWZpbmUJ CXJlY3Zmcm9tCQkJX3JlY3Zmcm9tCiAjZGVmaW5lCQlyZWN2bXNnCQkJCV9yZWN2bXNnCisjZGVm aW5lCQlyZWN2bW1zZwkJCV9yZWN2bW1zZwogI2RlZmluZQkJc2VsZWN0CQkJCV9zZWxlY3QKICNk ZWZpbmUJCXNlbV9jbG9zZQkJCV9zZW1fY2xvc2UKICNkZWZpbmUJCXNlbV9kZXN0cm95CQkJX3Nl bV9kZXN0cm95CkBAIC0yMjAsNiArMjIxLDcgQEAKICNkZWZpbmUJCXNlbV91bmxpbmsJCQlfc2Vt X3VubGluawogI2RlZmluZQkJc2VtX3dhaXQJCQlfc2VtX3dhaXQKICNkZWZpbmUJCXNlbmRtc2cJ CQkJX3NlbmRtc2cKKyNkZWZpbmUJCXNlbmRtbXNnCQkJX3NlbmRtbXNnCiAjZGVmaW5lCQlzZW5k dG8JCQkJX3NlbmR0bwogI2RlZmluZQkJc2V0c29ja29wdAkJCV9zZXRzb2Nrb3B0CiAvKiNkZWZp bmUJCXNpZ2FjdGlvbgkJCV9zaWdhY3Rpb24qLwpkaWZmIC0tZ2l0IGEvbGliL2xpYmMvaW5jbHVk ZS91bi1uYW1lc3BhY2UuaCBiL2xpYi9saWJjL2luY2x1ZGUvdW4tbmFtZXNwYWNlLmgKaW5kZXgg ZjMxZmE3YS4uMDIzMzM0OCAxMDA2NDQKLS0tIGEvbGliL2xpYmMvaW5jbHVkZS91bi1uYW1lc3Bh Y2UuaAorKysgYi9saWIvbGliYy9pbmNsdWRlL3VuLW5hbWVzcGFjZS5oCkBAIC0xODksNiArMTg5 LDcgQEAKICN1bmRlZgkJcmVhZHYKICN1bmRlZgkJcmVjdmZyb20KICN1bmRlZgkJcmVjdm1zZwor I3VuZGVmCQlyZWN2bW1zZwogI3VuZGVmCQlzZWxlY3QKICN1bmRlZgkJc2VtX2Nsb3NlCiAjdW5k ZWYJCXNlbV9kZXN0cm95CkBAIC0yMDEsNiArMjAyLDcgQEAKICN1bmRlZgkJc2VtX3VubGluawog I3VuZGVmCQlzZW1fd2FpdAogI3VuZGVmCQlzZW5kbXNnCisjdW5kZWYJCXNlbmRtbXNnCiAjdW5k ZWYJCXNlbmR0bwogI3VuZGVmCQlzZXRzb2Nrb3B0CiAjdW5kZWYJCXNpZ2FjdGlvbgpkaWZmIC0t Z2l0IGEvbGliL2xpYmMvc3lzL01ha2VmaWxlLmluYyBiL2xpYi9saWJjL3N5cy9NYWtlZmlsZS5p bmMKaW5kZXggZTRmZTFiMi4uNWY4YjY5OSAxMDA2NDQKLS0tIGEvbGliL2xpYmMvc3lzL01ha2Vm aWxlLmluYworKysgYi9saWIvbGliYy9zeXMvTWFrZWZpbGUuaW5jCkBAIC0yOCw2ICsyOCw4IEBA IFNSQ1MrPSBmdXRpbWVucy5jIHV0aW1lbnNhdC5jCiBOT0FTTSs9IGZ1dGltZW5zLm8gdXRpbWVu c2F0Lm8KIFBTRVVETys9IF9mdXRpbWVucy5vIF91dGltZW5zYXQubwogCitTUkNTKz0gcmVjdm1t c2cuYyBzZW5kbW1zZy5jCisKIElOVEVSUE9TRUQgPSBcCiAJYWNjZXB0IFwKIAlhY2NlcHQ0IFwK ZGlmZiAtLWdpdCBhL2xpYi9saWJjL3N5cy9TeW1ib2wubWFwIGIvbGliL2xpYmMvc3lzL1N5bWJv bC5tYXAKaW5kZXggN2IzMjU3Yy4uZGMyZWQwZSAxMDA2NDQKLS0tIGEvbGliL2xpYmMvc3lzL1N5 bWJvbC5tYXAKKysrIGIvbGliL2xpYmMvc3lzL1N5bWJvbC5tYXAKQEAgLTM5OSw2ICszOTksOCBA QCBGQlNEXzEuNCB7CiAJdXRpbWVuc2F0OwogCW51bWFfc2V0YWZmaW5pdHk7CiAJbnVtYV9nZXRh ZmZpbml0eTsKKwlzZW5kbW1zZzsKKwlyZWN2bW1zZzsKIH07CiAKIEZCU0Rwcml2YXRlXzEuMCB7 CmRpZmYgLS1naXQgYS9saWIvbGliYy9zeXMvcmVjdi4yIGIvbGliL2xpYmMvc3lzL3JlY3YuMgpp bmRleCAzMjZlN2ZmLi5mZDJiMmExIDEwMDY0NAotLS0gYS9saWIvbGliYy9zeXMvcmVjdi4yCisr KyBiL2xpYi9saWJjL3N5cy9yZWN2LjIKQEAgLTM0LDggKzM0LDkgQEAKIC5TaCBOQU1FCiAuTm0g cmVjdiAsCiAuTm0gcmVjdmZyb20gLAotLk5tIHJlY3Ztc2cKLS5OZCByZWNlaXZlIGEgbWVzc2Fn ZSBmcm9tIGEgc29ja2V0CisuTm0gcmVjdm1zZyAsCisuTm0gcmVjdm1tc2cKKy5OZCByZWNlaXZl IG1lc3NhZ2UocykgZnJvbSBhIHNvY2tldAogLlNoIExJQlJBUlkKIC5MYiBsaWJjCiAuU2ggU1lO T1BTSVMKQEAgLTQ3LDExICs0OCwxNSBAQAogLkZuIHJlY3Zmcm9tICJpbnQgcyIgInZvaWQgKmJ1 ZiIgInNpemVfdCBsZW4iICJpbnQgZmxhZ3MiICJzdHJ1Y3Qgc29ja2FkZHIgKiByZXN0cmljdCBm cm9tIiAic29ja2xlbl90ICogcmVzdHJpY3QgZnJvbWxlbiIKIC5GdCBzc2l6ZV90CiAuRm4gcmVj dm1zZyAiaW50IHMiICJzdHJ1Y3QgbXNnaGRyICptc2ciICJpbnQgZmxhZ3MiCisuRnQgc3NpemVf dAorLkZuIHJlY3ZtbXNnICJpbnQgcyIgInN0cnVjdCBtbXNnaGRyICptc2d2ZWMiICJzaXplX3Qg dmxlbiIgImludCBmbGFncyIgImNvbnN0IHN0cnVjdCB0aW1lc3BlYyAqdGltZW91dCIKIC5TaCBE RVNDUklQVElPTgogVGhlCiAuRm4gcmVjdmZyb20KIGFuZAogLkZuIHJlY3Ztc2cKK2FuZAorLkZu IHJlY3ZtbXNnCiBzeXN0ZW0gY2FsbHMKIGFyZSB1c2VkIHRvIHJlY2VpdmUgbWVzc2FnZXMgZnJv bSBhIHNvY2tldCwKIGFuZCBtYXkgYmUgdXNlZCB0byByZWNlaXZlIGRhdGEgb24gYSBzb2NrZXQg d2hldGhlciBvciBub3QKQEAgLTg0LDggKzg5LDMwIEBAIG51bGwgcG9pbnRlciBwYXNzZWQgYXMg aXRzCiAuRmEgZnJvbQogYXJndW1lbnQuCiAuUHAKLUFsbCB0aHJlZSByb3V0aW5lcyByZXR1cm4g dGhlIGxlbmd0aCBvZiB0aGUgbWVzc2FnZSBvbiBzdWNjZXNzZnVsCi1jb21wbGV0aW9uLgorVGhl CisuRm4gcmVjdm1tc2cKK2Z1bmN0aW9uIGlzIHVzZWQgdG8gcmVjZWl2ZSBtdWx0aXBsZQorbWVz c2FnZXMgYXQgYSBjYWxsLgorVGhlaXIgbnVtYmVyCitpcyBzdXBwbGllZCBieQorLkZhIHZsZW4g LgorVGhlIG1lc3NhZ2VzIGFyZSBwbGFjZWQgaW4gdGhlCisuRmEgbXNndmVjCit2ZWN0b3IgYWZ0 ZXIgcmVjZXB0aW9uLgorVGhlIHNpemUgb2YgZWFjaCByZWNlaXZlZCBtZXNzYWdlIGlzIHBsYWNl ZCBpbiB0aGUKKy5GYSBtc2dfbGVuCitmaWVsZCBvZiBlYWNoIGVsZW1lbnQgb2YgdGhlIHZlY3Rv ci4KK0lmCisuRmEgdGltZW91dAoraXMgTlVMTCB0aGUgY2FsbCB3aWxsIG5vcm1hbGx5IGJsb2Nr LiBPdGhlcndpc2UgaXQgd2lsbCB3YWl0IGZvciBkYXRhCitmb3IgdGhlIHNwZWNpZmllZCBhbW91 bnQgb2YgdGltZS4gSWYgdGhlIHRpbWVvdXQgZXhwaXJlcyBhbmQgdGhlcmUgaXMKK25vIGRhdGEg cmVjZWl2ZWQgYSB2YWx1ZSBvZiAwIGlzIHJldHVybmVkLiBwc2VsZWN0KDIpIGlzIHVzZWQgZm9y IHRoZQoraW1wbGVtZW50YXRpb24gb2YgdGhlIHRpbWVvdXQgbWVjaGFuaXNtLgorLlBwCitUaGUg Zmlyc3QgdGhyZWUgcm91dGluZXMgcmV0dXJuIHRoZSBsZW5ndGggb2YgdGhlIG1lc3NhZ2Ugb24g c3VjY2Vzc2Z1bAorY29tcGxldGlvbiB3aGVyZWFzCisuRm4gcmVjdm1tc2cKK3JldHVybnMgdGhl IG51bWJlciBvZiByZWNlaXZlZCBtZXNzYWdlcy4KIElmIGEgbWVzc2FnZSBpcyB0b28gbG9uZyB0 byBmaXQgaW4gdGhlIHN1cHBsaWVkIGJ1ZmZlciwKIGV4Y2VzcyBieXRlcyBtYXkgYmUgZGlzY2Fy ZGVkIGRlcGVuZGluZyBvbiB0aGUgdHlwZSBvZiBzb2NrZXQKIHRoZSBtZXNzYWdlIGlzIHJlY2Vp dmVkIGZyb20gKHNlZQpAQCAtMTAwLDcgKzEyNyw5IEBAIGluIHdoaWNoIGNhc2UgdGhlIHZhbHVl CiAuVmEgZXJybm8KIGlzIHNldCB0bwogLkVyIEVBR0FJTiAuCi1UaGUgcmVjZWl2ZSBjYWxscyBu b3JtYWxseSByZXR1cm4gYW55IGRhdGEgYXZhaWxhYmxlLAorVGhlIHJlY2VpdmUgY2FsbHMgZXhj ZXB0CisuRm4gcmVjdm1tc2cKK25vcm1hbGx5IHJldHVybiBhbnkgZGF0YSBhdmFpbGFibGUsCiB1 cCB0byB0aGUgcmVxdWVzdGVkIGFtb3VudCwKIHJhdGhlciB0aGFuIHdhaXRpbmcgZm9yIHJlY2Vp cHQgb2YgdGhlIGZ1bGwgYW1vdW50IHJlcXVlc3RlZDsKIHRoaXMgYmVoYXZpb3IgaXMgYWZmZWN0 ZWQgYnkgdGhlIHNvY2tldC1sZXZlbCBvcHRpb25zCkBAIC0xMjcsNiArMTU2LDkgQEAgb25lIG9y IG1vcmUgb2YgdGhlIHZhbHVlczoKIC5JdCBEdiBNU0dfV0FJVEFMTCBUYSB3YWl0IGZvciBmdWxs IHJlcXVlc3Qgb3IgZXJyb3IKIC5JdCBEdiBNU0dfRE9OVFdBSVQgVGEgZG8gbm90IGJsb2NrCiAu SXQgRHYgTVNHX0NNU0dfQ0xPRVhFQyBUYSBzZXQgcmVjZWl2ZWQgZmRzIGNsb3NlLW9uLWV4ZWMK Ky5JdCBEdiBNU0dfV0FJVEZPUk9ORSBUYSBkbyBub3QgYmxvY2sgYWZ0ZXIgcmVjZWl2aW5nIHRo ZSBmaXJzdCBtZXNzYWdlCisocmVsZXZhbnQgb25seSBmb3IKKy5GbiByZWN2bW1zZyApCiAuRWwK IC5QcAogVGhlCkBAIC0xNTgsNiArMTkwLDExIEBAIGlzIHNldCB0bwogVGhpcyBmbGFnIGlzIG5v dCBhdmFpbGFibGUgaW4gc3RyaWN0CiAuVG4gQU5TSQogb3IgQzk5IGNvbXBpbGF0aW9uIG1vZGUu CitUaGUKKy5EdiBNU0dfV0FJVEZPUk9ORQorZmxhZyBzZXRzIE1TR19ET05UV0FJVCBhZnRlciB0 aGUgZmlyc3QgbWVzc2FnZSBoYXMgYmVlbiByZWNlaXZlZC4gVGhpcyBmbGFnCitpcyBvbmx5IHJl bGV2YW50IGZvcgorLkZuIHJlY3ZtbXNnIC4KIC5QcAogVGhlCiAuRm4gcmVjdm1zZwpAQCAtMjkw LDkgKzMyNywzNCBAQCBjb250cm9sIGRhdGEgd2VyZSBkaXNjYXJkZWQgZHVlIHRvIGxhY2sgb2Yg c3BhY2UgaW4gdGhlIGJ1ZmZlcgogZm9yIGFuY2lsbGFyeSBkYXRhLgogLkR2IE1TR19PT0IKIGlz IHJldHVybmVkIHRvIGluZGljYXRlIHRoYXQgZXhwZWRpdGVkIG9yIG91dC1vZi1iYW5kIGRhdGEg d2VyZSByZWNlaXZlZC4KKy5QcAorVGhlCisuRm4gcmVjdm1tc2cKK3N5c3RlbSBjYWxsIHVzZXMg dGhlCisuRmEgbW1zZ2hkcgorc3RydWN0dXJlLiBJdHMgZm9ybSBpcyBhcyBmb2xsb3dzLCBhcyBk ZWZpbmVkIGluCisuSW4gc3lzL3NvY2tldC5oIDoKKy5CZCAtbGl0ZXJhbAorc3RydWN0IG1tc2do ZHIgeworCXN0cnVjdCBtc2doZHIJIG1zZ19oZHI7CS8qIG1lc3NhZ2UgaGVhZGVyICovCisJdW5z aWduZWQgaW50CSBtc2dfbGVuOwkvKiBtZXNzYWdlIGxlbmd0aCAqLworfTsKKy5FZAorLlBwCitG b3IKKy5GYSBtc2dfaGRyCitzZWUgYWJvdmUuIE9uIGRhdGEgcmVjZXB0aW9uIHRoZQorLkZhIG1z Z19sZW4KK2ZpZWxkIGlzIHVwZGF0ZWQgdG8gdGhlIGxlbmd0aCBvZiB0aGUgcmVjZWl2ZWQgbWVz c2FnZS4gT24KK2RhdGEgdHJhbnNtaXNzaW9uIGl0IGlzIHVwZGF0ZWQgdG8gdGhlIG51bWJlciBv ZgorY2hhcmFjdGVycyBzZW50LgogLlNoIFJFVFVSTiBWQUxVRVMKLVRoZXNlIGNhbGxzIHJldHVy biB0aGUgbnVtYmVyIG9mIGJ5dGVzIHJlY2VpdmVkLCBvciAtMQotaWYgYW4gZXJyb3Igb2NjdXJy ZWQuCitUaGVzZSBjYWxscyBleGNlcHQKKy5GbiByZWN2bW1zZworcmV0dXJuIHRoZSBudW1iZXIg b2YgYnl0ZXMgcmVjZWl2ZWQuCisuRm4gcmVjdm1tc2cKK3JldHVybnMgdGhlIG51bWJlciBvZiBt ZXNzYWdlcyByZWNlaXZlZC4KK0EgdmFsdWUgb2YgLTEgaXMgcmV0dXJuZWQgaWYgYW4gZXJyb3Ig b2NjdXJyZWQuCiAuU2ggRVJST1JTCiBUaGUgY2FsbHMgZmFpbCBpZjoKIC5CbCAtdGFnIC13aWR0 aCBFcgpkaWZmIC0tZ2l0IGEvbGliL2xpYmMvc3lzL3JlY3ZtbXNnLmMgYi9saWIvbGliYy9zeXMv cmVjdm1tc2cuYwpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi4xOWE5MzdiCi0t LSAvZGV2L251bGwKKysrIGIvbGliL2xpYmMvc3lzL3JlY3ZtbXNnLmMKQEAgLTAsMCArMSw5NiBA QAorLyoKKyAqIENvcHlyaWdodCAoYykgMjAxNiBCb3JpcyBBc3RhcmR6aGlldiwgU21hcnRjb20t QnVsZ2FyaWEgQUQKKyAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCisgKgorICogUmVkaXN0cmlidXRp b24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0Cisg KiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5n IGNvbmRpdGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNl IGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlKHMpLCB0 aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGFzCisg KiAgICB0aGUgZmlyc3QgbGluZXMgb2YgdGhpcyBmaWxlIHVubW9kaWZpZWQgb3RoZXIgdGhhbiB0 aGUgcG9zc2libGUKKyAqICAgIGFkZGl0aW9uIG9mIG9uZSBvciBtb3JlIGNvcHlyaWdodCBub3Rp Y2VzLgorICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNl IHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZShzKSwgdGhpcyBsaXN0IG9mIGNvbmRp dGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbgorICogICAgdGhlIGRvY3VtZW50 YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZQorICogICAgZGlz dHJpYnV0aW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIENPUFlS SUdIVCBIT0xERVIoUykgYGBBUyBJUycnIEFORCBBTlkKKyAqIEVYUFJFU1MgT1IgSU1QTElFRCBX QVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBMSUVE IFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VM QVIKKyAqIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQ09Q WVJJR0hUIEhPTERFUihTKSBCRQorICogTElBQkxFIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwg SU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUgorICogQ09OU0VRVUVOVElBTCBEQU1B R0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YKKyAqIFNV QlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRT OyBPUgorICogQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5Z IFRIRU9SWSBPRiBMSUFCSUxJVFksCisgKiBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QgTElB QklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRQorICogT1IgT1RIRVJXSVNFKSBB UklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwKKyAqIEVW RU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuCisgKi8KKwor I2luY2x1ZGUgPHN5cy9jZGVmcy5oPgorX19GQlNESUQoIiRGcmVlQlNEJCIpOworCisjaW5jbHVk ZSA8ZXJybm8uaD4KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNsdWRlIDxzeXMvc3lzY2Fs bC5oPgorI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KKyNpbmNsdWRlIDxzeXMvc2VsZWN0Lmg+Cisj aW5jbHVkZSA8cHRocmVhZC5oPgorI2luY2x1ZGUgImxpYmNfcHJpdmF0ZS5oIgorCisjZGVmaW5l IENNVFIocywgdGltZW91dCkJCQkJCQlcCisJZG8gewkJCQkJCQkJXAorCQlmZF9zZXQgZmRzOwkJ CQkJCVwKKwkJaW50IHJlczsJCQkJCQlcCisJCQkJCQkJCQlcCisJCUZEX1pFUk8oJmZkcyk7CQkJ CQkJXAorCQlGRF9TRVQoKHMpLCAmZmRzKTsJCQkJCVwKKwkJcmVzID0gX19zeXNfcHNlbGVjdCgo cykrMSwgJmZkcywgTlVMTCwgTlVMTCwgKHRpbWVvdXQpLCBOVUxMKTtcCisJCWlmIChyZXMgPT0g LTEgfHwgcmVzID09IDApCQkJCVwKKwkJCXJldHVybiAocmVzKTsJCQkJCVwKKwkJaWYgKCFGRF9J U1NFVCgocyksICZmZHMpKQkJCQlcCisJCQlyZXR1cm4gKC0xKTsJCQkJCVwKKwl9IHdoaWxlICgw KTsKKworc3NpemVfdAorcmVjdm1tc2coaW50IHMsIHN0cnVjdCBtbXNnaGRyICptc2d2ZWMsIHNp emVfdCB2bGVuLCBpbnQgZmxhZ3MsCisgICAgY29uc3Qgc3RydWN0IHRpbWVzcGVjICp0aW1lb3V0 KQoreworCXNpemVfdCBpLCByY3ZkOworCXNzaXplX3QgcmV0OworCisJaWYgKHRpbWVvdXQgIT0g TlVMTCkKKwkJQ01UUihzLCB0aW1lb3V0KTsKKworCXJldCA9IF9fc3lzX3JlY3Ztc2cocywgJm1z Z3ZlY1swXS5tc2dfaGRyLCBmbGFncyk7CisJaWYgKHJldCA9PSAtMSkKKwkJcmV0dXJuIChyZXQp OworCisJLyogQ2hlY2sgaW5pdGlhbGx5IGZvciB0aGUgcHJlc2VuY2Ugb2YgTVNHX1dBSVRGT1JP TkUuCisJICogVHVybiBvbiBNU0dfRE9OVFdBSVQgaWYgc2V0LiAqLworCWlmIChmbGFncyAmIE1T R19XQUlURk9ST05FKSB7CisJCWZsYWdzIHw9IE1TR19ET05UV0FJVDsKKwkJLyogVGhlIGtlcm5l bCBkb2Vzbid0IG5lZWQgdG8ga25vdyBhYm91dCB0aGlzIGZsYWcuICovCisJCWZsYWdzICY9IH5N U0dfV0FJVEZPUk9ORTsKKwl9CisKKwlyY3ZkID0gMTsKKwlmb3IgKGkgPSByY3ZkOyBpIDwgdmxl bjsgaSsrKSB7CisJCXJldCA9IF9fc3lzX3JlY3Ztc2cocywgJm1zZ3ZlY1tpXS5tc2dfaGRyLCBm bGFncyk7CisJCWlmIChyZXQgPT0gLTEpIHsKKwkJCWlmIChyY3ZkICE9IDApIHsKKwkJCQkvKiBX ZSd2ZSByZWNlaXZlZCBtZXNzYWdlcy4gTGV0IGNhbGxlciBrbm93LiAqLworCQkJCXJldHVybiAo cmN2ZCk7CisJCQl9CisJCQlyZXR1cm4gKHJldCk7CisJCX0KKworCQkvKiBTYXZlIHJlY2VpdmVk IGJ5dGVzICovCisJCW1zZ3ZlY1tpXS5tc2dfbGVuID0gcmV0OworCQlyY3ZkKys7CisJfQorCisJ cmV0dXJuIChyY3ZkKTsKK30KKworI3VuZGVmIENNVFIKZGlmZiAtLWdpdCBhL2xpYi9saWJjL3N5 cy9zZW5kLjIgYi9saWIvbGliYy9zeXMvc2VuZC4yCmluZGV4IDhmYTJjNjQuLjMzZmE1OGQgMTAw NjQ0Ci0tLSBhL2xpYi9saWJjL3N5cy9zZW5kLjIKKysrIGIvbGliL2xpYmMvc3lzL3NlbmQuMgpA QCAtMzQsOCArMzQsOSBAQAogLlNoIE5BTUUKIC5ObSBzZW5kICwKIC5ObSBzZW5kdG8gLAotLk5t IHNlbmRtc2cKLS5OZCBzZW5kIGEgbWVzc2FnZSBmcm9tIGEgc29ja2V0CisuTm0gc2VuZG1zZyAs CisuTm0gc2VuZG1tc2cKKy5OZCBzZW5kIG1lc3NhZ2UocykgZnJvbSBhIHNvY2tldAogLlNoIExJ QlJBUlkKIC5MYiBsaWJjCiAuU2ggU1lOT1BTSVMKQEAgLTQ3LDYgKzQ4LDggQEAKIC5GbiBzZW5k dG8gImludCBzIiAiY29uc3Qgdm9pZCAqbXNnIiAic2l6ZV90IGxlbiIgImludCBmbGFncyIgImNv bnN0IHN0cnVjdCBzb2NrYWRkciAqdG8iICJzb2NrbGVuX3QgdG9sZW4iCiAuRnQgc3NpemVfdAog LkZuIHNlbmRtc2cgImludCBzIiAiY29uc3Qgc3RydWN0IG1zZ2hkciAqbXNnIiAiaW50IGZsYWdz IgorLkZ0IHNzaXplX3QKKy5GbiBzZW5kbW1zZyAiaW50IHMiICJzdHJ1Y3QgbW1zZ2hkciAqbXNn dmVjIiAic2l6ZV90IHZsZW4iICJpbnQgZmxhZ3MiCiAuU2ggREVTQ1JJUFRJT04KIFRoZQogLkZu IHNlbmQKQEAgLTU1LDggKzU4LDEwIEBAIGFuZAogLkZuIHNlbmR0bwogYW5kCiAuRm4gc2VuZG1z ZworYW5kCisuRm4gc2VuZG1tc2cKIHN5c3RlbSBjYWxscwotYXJlIHVzZWQgdG8gdHJhbnNtaXQg YSBtZXNzYWdlIHRvIGFub3RoZXIgc29ja2V0LgorYXJlIHVzZWQgdG8gdHJhbnNtaXQgb25lIG9y IG11bHRpcGxlIG1lc3NhZ2VzICh3aXRoIHRoZSBsYXR0ZXIgY2FsbCkgdG8gYW5vdGhlciBzb2Nr ZXQuCiBUaGUKIC5GbiBzZW5kCiBmdW5jdGlvbgpAQCAtNjYsNiArNzEsOCBAQCBzdGF0ZSwgd2hp bGUKIC5GbiBzZW5kdG8KIGFuZAogLkZuIHNlbmRtc2cKK2FuZAorLkZuIHNlbmRtbXNnCiBtYXkg YmUgdXNlZCBhdCBhbnkgdGltZS4KIC5QcAogVGhlIGFkZHJlc3Mgb2YgdGhlIHRhcmdldCBpcyBn aXZlbiBieQpAQCAtODEsNiArODgsMTggQEAgdW5kZXJseWluZyBwcm90b2NvbCwgdGhlIGVycm9y CiBpcyByZXR1cm5lZCwgYW5kCiB0aGUgbWVzc2FnZSBpcyBub3QgdHJhbnNtaXR0ZWQuCiAuUHAK K1RoZQorLkZuIHNlbmRtbXNnCitmdW5jdGlvbiBzZW5kcyBtdWx0aXBsZSBtZXNzYWdlcyBhdCBh IGNhbGwuCitUaGV5IGFyZSBnaXZlbiBieSB0aGUKKy5GYSBtc2d2ZWMKK3ZlY3RvciBhbG9uZyB3 aXRoCisuRmEgdmxlbgorc3BlY2lmeWluZyBpdHMgc2l6ZS4gVGhlIG51bWJlciBvZgorY2hhcmFj dGVycyBzZW50IHBlciBlYWNoIG1lc3NhZ2UgaXMgcGxhY2VkIGluIHRoZQorLkZhIG1zZ19sZW4K K2ZpZWxkIG9mIGVhY2ggZWxlbWVudCBvZiB0aGUgdmVjdG9yIGFmdGVyIHRyYW5zbWlzc2lvbi4K Ky5QcAogTm8gaW5kaWNhdGlvbiBvZiBmYWlsdXJlIHRvIGRlbGl2ZXIgaXMgaW1wbGljaXQgaW4g YQogLkZuIHNlbmQgLgogTG9jYWxseSBkZXRlY3RlZCBlcnJvcnMgYXJlIGluZGljYXRlZCBieSBh IHJldHVybiB2YWx1ZSBvZiAtMS4KQEAgLTEzOCwxMCArMTU3LDE2IEBAIFNlZQogLlhyIHJlY3Yg MgogZm9yIGEgZGVzY3JpcHRpb24gb2YgdGhlCiAuRmEgbXNnaGRyCitzdHJ1Y3R1cmUgYW5kIHRo ZQorLkZhIG1tc2doZHIKIHN0cnVjdHVyZS4KIC5TaCBSRVRVUk4gVkFMVUVTCi1UaGUgY2FsbCBy ZXR1cm5zIHRoZSBudW1iZXIgb2YgY2hhcmFjdGVycyBzZW50LCBvciAtMQotaWYgYW4gZXJyb3Ig b2NjdXJyZWQuCitBbGwgY2FsbHMgZXhjZXB0CisuRm4gc2VuZG1tc2cKK3JldHVybiB0aGUgbnVt YmVyIG9mIGNoYXJhY3RlcnMgc2VudC4gVGhlCisuRm4gc2VuZG1tc2cKK2NhbGwgcmV0dXJucyB0 aGUgbnVtYmVyIG9mIG1lc3NhZ2VzIHNlbnQuCitJZiBhbiBlcnJvciBvY2N1cnJlZCBhIHZhbHVl IG9mIC0xIGlzIHJldHVybmVkLgogLlNoIEVSUk9SUwogVGhlCiAuRm4gc2VuZApAQCAtMTQ5LDYg KzE3NCw4IEBAIGZ1bmN0aW9uIGFuZAogLkZuIHNlbmR0bwogYW5kCiAuRm4gc2VuZG1zZworYW5k CisuRm4gc2VuZG1tc2cKIHN5c3RlbSBjYWxscwogZmFpbCBpZjoKIC5CbCAtdGFnIC13aWR0aCBF cgpkaWZmIC0tZ2l0IGEvbGliL2xpYmMvc3lzL3NlbmRtbXNnLmMgYi9saWIvbGliYy9zeXMvc2Vu ZG1tc2cuYwpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi5jZWYzNWEzCi0tLSAv ZGV2L251bGwKKysrIGIvbGliL2xpYmMvc3lzL3NlbmRtbXNnLmMKQEAgLTAsMCArMSw2MyBAQAor LyoKKyAqIENvcHlyaWdodCAoYykgMjAxNiBCb3JpcyBBc3RhcmR6aGlldiwgU21hcnRjb20tQnVs Z2FyaWEgQUQKKyAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCisgKgorICogUmVkaXN0cmlidXRpb24g YW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisgKiBt b2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNv bmRpdGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNv ZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlKHMpLCB0aGlz IGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGFzCisgKiAg ICB0aGUgZmlyc3QgbGluZXMgb2YgdGhpcyBmaWxlIHVubW9kaWZpZWQgb3RoZXIgdGhhbiB0aGUg cG9zc2libGUKKyAqICAgIGFkZGl0aW9uIG9mIG9uZSBvciBtb3JlIGNvcHlyaWdodCBub3RpY2Vz LgorICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRo ZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZShzKSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlv bnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbgorICogICAgdGhlIGRvY3VtZW50YXRp b24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZQorICogICAgZGlzdHJp YnV0aW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIENPUFlSSUdI VCBIT0xERVIoUykgYGBBUyBJUycnIEFORCBBTlkKKyAqIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJS QU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBMSUVEIFdB UlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIK KyAqIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQ09QWVJJ R0hUIEhPTERFUihTKSBCRQorICogTElBQkxFIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5D SURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUgorICogQ09OU0VRVUVOVElBTCBEQU1BR0VT IChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YKKyAqIFNVQlNU SVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBP UgorICogQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRI RU9SWSBPRiBMSUFCSUxJVFksCisgKiBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QgTElBQklM SVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRQorICogT1IgT1RIRVJXSVNFKSBBUklT SU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwKKyAqIEVWRU4g SUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuCisgKi8KKworI2lu Y2x1ZGUgPHN5cy9jZGVmcy5oPgorX19GQlNESUQoIiRGcmVlQlNEJCIpOworCisjaW5jbHVkZSA8 ZXJybm8uaD4KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNsdWRlIDxzeXMvc3lzY2FsbC5o PgorI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KKyNpbmNsdWRlIDxwdGhyZWFkLmg+CisjaW5jbHVk ZSAibGliY19wcml2YXRlLmgiCisKK3NzaXplX3QKK3NlbmRtbXNnKGludCBzLCBzdHJ1Y3QgbW1z Z2hkciAqbXNndmVjLCBzaXplX3QgdmxlbiwgaW50IGZsYWdzKQoreworCXNpemVfdCBpLCBzZW50 OworCXNzaXplX3QgcmV0OworCisJc2VudCA9IDA7CisJZm9yIChpID0gMDsgaSA8IHZsZW47IGkr KykgeworCQlyZXQgPSBfX3N5c19zZW5kbXNnKHMsICZtc2d2ZWNbaV0ubXNnX2hkciwgZmxhZ3Mp OworCQlpZiAocmV0ID09IC0xKSB7CisJCQlpZiAoc2VudCAhPSAwKSB7CisJCQkJLyogV2UgaGF2 ZSBzZW50IG1lc3NhZ2VzLiBMZXQgY2FsbGVyIGtub3cuICovCisJCQkJcmV0dXJuIChzZW50KTsK KwkJCX0KKwkJCXJldHVybiAocmV0KTsKKwkJfQorCisJCS8qIFNhdmUgc2VudCBieXRlcyAqLwor CQltc2d2ZWNbaV0ubXNnX2xlbiA9IHJldDsKKwkJc2VudCsrOworCX0KKworCXJldHVybiAoc2Vu dCk7Cit9CmRpZmYgLS1naXQgYS9zeXMvc3lzL3NvY2tldC5oIGIvc3lzL3N5cy9zb2NrZXQuaApp bmRleCAxOGUyZGUxLi5kOTVmMjllIDEwMDY0NAotLS0gYS9zeXMvc3lzL3NvY2tldC5oCisrKyBi L3N5cy9zeXMvc29ja2V0LmgKQEAgLTQzNSw2ICs0MzUsMTEgQEAgc3RydWN0IG1zZ2hkciB7CiAj aWZkZWYgX0tFUk5FTAogI2RlZmluZQlNU0dfU09DQUxMQkNLICAgMHgxMDAwMAkJLyogZm9yIHVz ZSBieSBzb2NrZXQgY2FsbGJhY2tzIC0gc29yZWNlaXZlIChUQ1ApICovCiAjZW5kaWYKKyNpZm5k ZWYgX0tFUk5FTAorI2lmZGVmIF9fQlNEX1ZJU0lCTEUKKyNkZWZpbmUgTVNHX1dBSVRGT1JPTkUJ MHgxMDAwMDAJLyogdXNlZCBpbiByZWN2bW1zZygpICovCisjZW5kaWYgLyogX19CU0RfVklTSUJM RSAqLworI2VuZGlmIC8qICFfS0VSTkVMICovCiAKIC8qCiAgKiBIZWFkZXIgZm9yIGFuY2lsbGFy eSBkYXRhIG9iamVjdHMgaW4gbXNnX2NvbnRyb2wgYnVmZmVyLgpAQCAtNTk1LDYgKzYwMCwxOCBA QCBzdHJ1Y3Qgc2ZfaGR0ciB7CiAjZW5kaWYgLyogX0tFUk5FTCAqLwogI2VuZGlmIC8qIF9fQlNE X1ZJU0lCTEUgKi8KIAorI2lmbmRlZiBfS0VSTkVMCisjaWZkZWYgX19CU0RfVklTSUJMRQorLyoK KyAqIFNlbmQvcmVjdm1tc2cgc3BlY2lmaWMgc3RydWN0dXJlKHMpCisgKi8KK3N0cnVjdCBtbXNn aGRyIHsKKwlzdHJ1Y3QgbXNnaGRyCW1zZ19oZHI7CQkvKiBtZXNzYWdlIGhlYWRlciAqLworCXVu c2lnbmVkIGludAltc2dfbGVuOwkJLyogbWVzc2FnZSBsZW5ndGggKi8KK307CisjZW5kaWYgLyog X19CU0RfVklTSUJMRSAqLworI2VuZGlmIC8qICFfS0VSTkVMICovCisKICNpZm5kZWYJX0tFUk5F TAogCiAjaW5jbHVkZSA8c3lzL2NkZWZzLmg+CkBAIC02MTUsMTEgKzYzMiwxOSBAQCBpbnQJbGlz dGVuKGludCwgaW50KTsKIHNzaXplX3QJcmVjdihpbnQsIHZvaWQgKiwgc2l6ZV90LCBpbnQpOwog c3NpemVfdAlyZWN2ZnJvbShpbnQsIHZvaWQgKiwgc2l6ZV90LCBpbnQsIHN0cnVjdCBzb2NrYWRk ciAqIF9fcmVzdHJpY3QsIHNvY2tsZW5fdCAqIF9fcmVzdHJpY3QpOwogc3NpemVfdAlyZWN2bXNn KGludCwgc3RydWN0IG1zZ2hkciAqLCBpbnQpOworI2lmIF9fQlNEX1ZJU0lCTEUKK3N0cnVjdCB0 aW1lc3BlYzsKK3NzaXplX3QJcmVjdm1tc2coaW50LCBzdHJ1Y3QgbW1zZ2hkciAqLCBzaXplX3Qs IGludCwKKyAgICBjb25zdCBzdHJ1Y3QgdGltZXNwZWMgKik7CisjZW5kaWYKIHNzaXplX3QJc2Vu ZChpbnQsIGNvbnN0IHZvaWQgKiwgc2l6ZV90LCBpbnQpOwogc3NpemVfdAlzZW5kdG8oaW50LCBj b25zdCB2b2lkICosCiAJICAgIHNpemVfdCwgaW50LCBjb25zdCBzdHJ1Y3Qgc29ja2FkZHIgKiwg c29ja2xlbl90KTsKIHNzaXplX3QJc2VuZG1zZyhpbnQsIGNvbnN0IHN0cnVjdCBtc2doZHIgKiwg aW50KTsKICNpZiBfX0JTRF9WSVNJQkxFCitzc2l6ZV90CXNlbmRtbXNnKGludCwgc3RydWN0IG1t c2doZHIgKiwgc2l6ZV90LCBpbnQpOworI2VuZGlmCisjaWYgX19CU0RfVklTSUJMRQogaW50CXNl bmRmaWxlKGludCwgaW50LCBvZmZfdCwgc2l6ZV90LCBzdHJ1Y3Qgc2ZfaGR0ciAqLCBvZmZfdCAq LCBpbnQpOwogaW50CXNldGZpYihpbnQpOwogI2VuZGlmCg== --001a114715826cd8660529e8a863--