From owner-freebsd-net@freebsd.org Wed Jan 27 10:19:12 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19641A6F36C for ; Wed, 27 Jan 2016 10:19:12 +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 E60871EDE for ; Wed, 27 Jan 2016 10:19:11 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id E11C8A6F368; Wed, 27 Jan 2016 10:19:11 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DFB7BA6F366; Wed, 27 Jan 2016 10:19:11 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 6647C1EDB; Wed, 27 Jan 2016 10:19:11 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id 123so144879869wmz.0; Wed, 27 Jan 2016 02:19:11 -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=WC9W5H6mMXiCFJRU9WXALfCSEx5zg39f+zZ4DnRmd48=; b=gPNpyxGaRN6sgZz2ZQHZQfWAq6nyXy8EHAPAeQaTj4wVLscLtvqyICvuGXjpZxWoYk t5X1g0Npzur++LOBv9Ho216+p9uensJHjZddvxoOnf4x7dkI+dC6Vy7zj41L4Njsw5za pAQjuYGaFBS7ncttLcyJcgwccd/Lkn1HBQCP+M6blhO88z28TSYdcsrvll+Pz6igiEzx 7VMK0phhOn8loA7DjB/Xbcyz5Uyajvit0BB3ZPx+EPaTn2mVoSGqutpbir0z4/EmV9Oa Rh6OBSmOjiogNoXowJ3adb/Bj3hUonAIe1W4oJpwnR5235UPSj2kyhnf224AP93UyeWP NsVQ== 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=WC9W5H6mMXiCFJRU9WXALfCSEx5zg39f+zZ4DnRmd48=; b=G9EgklghR/skg88bGHFGKVCn/BFpSQ7O1POiTzJXbymWpHqc6lFgIAEx30yDij9ZM6 JCDwbHM1L3Mh5RHVADzn85Hsu4I83gAs5daUfqqv0+X/I2WH6ct1LqqaHubaYa7t+C0g g6/Kfj1Y2tlk30fvNSZgmIXetDi2bTH2mbQJco+hszWOYE0/urtDDBGiwhO/qzLGjIM3 ZlUQNi04OIQEtWSZvosF7UuSBTBJ1/g0LL64CuzfYTlMPiTiekanqWpbmmEbjiVucO6e tx03tRuw9GTlrnLyBL8dDIcBHp6sn7g3jmZXT9OgU23O0FjFK3M/hpXyJQJlpEUWFR+A MFIw== X-Gm-Message-State: AG10YOSRhmBJMECUkWGSI6qL0iBMpBbtdtCxikWV6qvv1kGcU9377JC4vs/fU8cokX9MSzFU1sRutFL+jFLuag== MIME-Version: 1.0 X-Received: by 10.194.119.161 with SMTP id kv1mr23282212wjb.135.1453889949887; Wed, 27 Jan 2016 02:19:09 -0800 (PST) Received: by 10.28.136.148 with HTTP; Wed, 27 Jan 2016 02:19:09 -0800 (PST) In-Reply-To: References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> <20160127013145.36f2aaef@ernst.home> <20160127132558.W985@besplex.bde.org> Date: Wed, 27 Jan 2016 12:19:09 +0200 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Boris Astardzhiev To: Kevin Oberman Cc: Bruce Evans , Gary Jennejohn , Daniel Eischen , threads@freebsd.org, Luigi Rizzo , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 10:19:12 -0000 ba>Is it possible that ppoll() doesn't return an error and yet revents ba>have set either POLLERR or POLLHUP or POLLNVAL? Apart from timeout. On Wed, Jan 27, 2016 at 12:14 PM, Boris Astardzhiev < boris.astardzhiev@gmail.com> wrote: > Hello, > > I've made a few changes in the patch as recommended here starting with > the switch to ppoll(). I have a question since it's not quite clear to me > as written > in the manpage. Is it possible that ppoll() doesn't return an error and > yet revents > have set either POLLERR or POLLHUP or POLLNVAL? > > See patch and comments are again welcomed. > > > On Wed, Jan 27, 2016 at 6:07 AM, Kevin Oberman > wrote: > >> Since this has become a debate on programming style, it seem appropriate >> to mention that Edward Yourdan passed away last Tuesday. For those too >> young to recognize the name, he was the developer of modern structured >> programming. He did recognize the style rules are important, but not >> iron-clad. >> >> Kevin Oberman, Part time kid herder and retired Network Engineer >> E-mail: rkoberman@gmail.com >> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 >> >> On Tue, Jan 26, 2016 at 7:04 PM, Bruce Evans >> wrote: >> >>> On Wed, 27 Jan 2016, Gary Jennejohn wrote: >>> >>> On Tue, 26 Jan 2016 17:46:52 -0500 (EST) >>>> Daniel Eischen wrote: >>>> >>>> On Tue, 26 Jan 2016, Gary Jennejohn wrote: >>>>> >>>>> On Tue, 26 Jan 2016 09:06:39 -0800 >>>>>> Luigi Rizzo wrote: >>>>>> >>>>>> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >>>>>>> wrote: >>>>>>> >>>>>>>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >>>>>>>> >>>>>>>>> +ssize_t >>>>>>>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, >>>>>>>>> int flags, >>>>>>>>> + const struct timespec *__restrict timeout) >>>>>>>>> +{ >>>>>>>>> + size_t i, rcvd; >>>>>>>>> + ssize_t ret; >>>>>>>>> + >>>>>>>>> + if (timeout != NULL) { >>>>>>>>> + fd_set fds; >>>>>>>>> + int res; >>>>>>>>> >>>>>>>> Please move all local definitions to the beginning of the function. >>>>>>>> >>>>>>> >>>>>>> This style recommendation was from 30 years ago and is >>>>>>> bad programming practice, as it tends to complicate analysis >>>>>>> for the human and increase the chance of improper usage of >>>>>>> variables. >>>>>>> >>>>>>> We should move away from this for new code. >>>>>>> >>>>>> >>>>>> Really? I personally find having all variables grouped together >>>>>> much easier to understand. Stumbling across declarations in the >>>>>> middle of the code in a for-loop, for example, takes me by surprise. >>>>>> >>>>> >>> +1 >>> >>> I used to program in a strict version of the "new" style 25-30 years >>> ago, but learned better. In the strict version, every variable must >>> have minimal scope, so squillions of inner blocks are needed to limit >>> the scopes. Some deeply nested of course. This is a good obfuscation. >>> It even breaks -Wshadow by letting you have unrelated variables named >>> 'i' that don't shadow each other because their scope is limited. Such >>> variables are good in separate functions but not in the same function. >>> Understanding the code to see that the variables are actually unrelated >>> requires counting more braces than usual. If you don't do this >>> strictly then you get a random style with some variables declared at >>> the top and some in inner blocks for mostly historical reasons. A >>> strict style with all of the variables at the top is much easier to >>> write and read. >>> >>> I also greatly dislike initializing variables in their declarations. >>>>>> >>>>>> Maybe I'm just old fashioned since I have been writing C-code for >>>>>> more than 30 years. >>>>>> >>>>> >>>>> +1 >>>>> >>>>> Probably should be discouraged, but allowed on a case-by-case >>>>> basis. One could argue that if you need to declaration blocks >>>>> in the middle of code, then that code is too complex and should >>>>> be broken out into a separate function. >>>>> >>>> >>>> Right. >>>> >>> >>> Lots of inner blocks are good for both making simple code look complex >>> and making it easier to write the complex code in the same function, >>> at least if you use a tiny indentation so that you can have 40 levels >>> of indentation without needing a 500-column terminal. >>> >>> And code like this >>>> >>>> int func(void) >>>> { >>>> int baz, zot; >>>> [some more code] >>>> if (zot < 5) >>>> { >>>> int baz = 3; >>>> [more code] >>>> } >>>> [some more code] >>>> } >>>> >>>> is even worse. The compiler (clang) seems to consider this to >>>> merely be a reinitialization of baz, but a human might be confused. >>>> >>> >>> No, that is a different baz, and is warned about by Wshadow. >>> >>> Something like for (int i = 0; i < 2; i++) is IMHO OK. >>>> >>> >>> Except it is C++ style which is so forbidden that style(9) doesn't >>> know that it needs a rule to forbid it. >>> >>> The worst is C++ style that doesn't limit the scope -- a bunch of >>> variables at the top and then somewhere in the middle of the function >>> another variable is needed and it is declared at top level of the >>> function scope. I sometimes do this when in a hurry. The strict >>> K&R-C90 style requires opening an inner block to do little more than >>> hold the declaration and then (re)indenting and (re)formatting all >>> the code in the inner block. The C++ style reduces writability and >>> readability in a different way. It doesn't cause excessive indentation >>> but it doesn't limit the scope much differently than putting all the >>> declarations at the top. At least the reader can find the declarations >>> easily when they are at the top. >>> >>> Bruce >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> >