From owner-freebsd-arch@FreeBSD.ORG Tue May 15 06:53:34 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B3BD16A402 for ; Tue, 15 May 2007 06:53:34 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.239]) by mx1.freebsd.org (Postfix) with ESMTP id CB38213C457 for ; Tue, 15 May 2007 06:53:33 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: by nz-out-0506.google.com with SMTP id s1so39684nze for ; Mon, 14 May 2007 23:53:33 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=QgCVjqAD4f4qwSaBefXQDvSJFrdjqssPoJb/2IrjUDpDa8zJNHRwLI1gp82SeQitptQU4fhs0qBT7y0kBMIWmwnlTVFOxKsRdEBdp8Kk2FpH3W+hXpMGtM1Mose+ZBXtM5kLAzbz+hVJuI990/KSmeT3WuNzarQtJNE50O/xswA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=mhm0PN6rSnC0pV/17xSyPe7PDL0LCutcpMsjFb7y8SQbtxrZPfb/DUTMM8HN6P4fw68XM19JVBMelUcpU4+TeYJ0wsl4mbmkH5zYKufXGL9nddkLjWIB4xpHd6pnsv9LGJucBJL5XVNLByr6FQu8mQExUs7B6QEFI/atc4aDTV8= Received: by 10.114.174.2 with SMTP id w2mr840982wae.1179212012749; Mon, 14 May 2007 23:53:32 -0700 (PDT) Received: by 10.115.54.2 with HTTP; Mon, 14 May 2007 23:53:32 -0700 (PDT) Message-ID: Date: Tue, 15 May 2007 06:53:32 +0000 From: MQ To: MQ , freebsd-arch@freebsd.org In-Reply-To: <20070514150550.GA73252@owl.midgard.homeip.net> MIME-Version: 1.0 References: <20070514150550.GA73252@owl.midgard.homeip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: A problem with the select(2) interface X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2007 06:53:34 -0000 2007/5/14, Erik Trulsson : > > On Mon, May 14, 2007 at 10:29:15PM +0800, MQ wrote: > > Hi, > > I'm writing a network application these days, for compatibility, I > choose > > the select(2) interface to do event polling. When using it, I'm curious > > about the fact that the type of the final parameter is `struct timeval > *'. I > > skimmed through the codes in /sys/kern/sys_generic.c, there is nothing > > written to this address. So, I think if we can use `const struct timeval > *' > > instead? This type can inform the users explicitly that we do NOT modify > the > > timeval struct. But I'm not sure if this modification will conflict with > the > > POSIX standard. Will you please tell me your considerations? Any > suggestions > > will be appreciated. > > Thanks. > > Some other implementations *do* write to that adress. > From the select(2) manpage on a Linux system: > > On Linux, select() modifies timeout to reflect the amount of time not > slept; most other imple- > mentations do not do this. (POSIX.1-2001 permits either behaviour.) > This causes problems both > when Linux code which reads timeout is ported to other operating > systems, and when code is > ported to Linux that reuses a struct timeval for multiple select()s > in a loop without reini- > tializing it. Consider timeout to be undefined after select() returns. > > The FreeBSD select(2) manpage says: > > BUGS > Version 2 of the Single UNIX Specification (`SUSv2'') allows systems > to > modify the original timeout in place. Thus, it is unwise to assume > that > the timeout value will be unmodified by the select() system call. > > > > > > -- > > Erik Trulsson > ertr1013@student.uu.se > I've considered that some OSes may write to that address before I initially posted to this mailing list. The key point here is that FreeBSD does NOT do this, and I want to know the committers' opinions about adding a `const' qualifier to the type.