From owner-freebsd-arch@FreeBSD.ORG Thu May 17 11:09:27 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 C20DC16A402 for ; Thu, 17 May 2007 11:09:27 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.225]) by mx1.freebsd.org (Postfix) with ESMTP id 6AE9E13C45B for ; Thu, 17 May 2007 11:09:27 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: by nz-out-0506.google.com with SMTP id s1so963568nze for ; Thu, 17 May 2007 04:09:26 -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:cc:in-reply-to:mime-version:content-type:references; b=H3oKpEx2bhbwC9B/6n2uxvawWfkkq4yQ1p0eVnqDdIH0m4i6lCBrlZ3Tq4py2CyXyMUII6/zULpLgJavLoeu3ZN8Waxz+fhW4yf7j60yj7MTWKFUdQmvHTeJN3hnitmB6gjedmx+MheyWJFHxKLSIyQXZS0SBvtdtvNr/4Qe7Rk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=QaFPQd2C8BVWxigM4lcosxTwi8YjHkQvzgLBe4IGZdTCYIStTibs2EZgwsPLr0oLpKypDSjzAhqaulATARgNr6BhnLJ7cK9Fc7lsd/SLDDl7NW2hmX/zeFqTZLGmYAJq80jhTd/m2rwBUyQ/5UnbxthDyeeGJh9BHPzdxl3NUkY= Received: by 10.114.167.2 with SMTP id p2mr144411wae.1179400159152; Thu, 17 May 2007 04:09:19 -0700 (PDT) Received: by 10.115.54.2 with HTTP; Thu, 17 May 2007 04:09:19 -0700 (PDT) Message-ID: Date: Thu, 17 May 2007 19:09:19 +0800 From: MQ To: "Peter Jeremy" In-Reply-To: <20070517094445.GD1149@turion.vk2pj.dyndns.org> MIME-Version: 1.0 References: <86odknqvf3.fsf@dwp.des.no> <86wszah2ua.fsf@dwp.des.no> <86fy5wkim5.fsf@dwp.des.no> <20070517094445.GD1149@turion.vk2pj.dyndns.org> 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: freebsd-arch@freebsd.org 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: Thu, 17 May 2007 11:09:27 -0000 2007/5/17, Peter Jeremy : > > On 2007-May-16 15:23:14 +0200, Dag-Erling Smrgrav wrote: > >MQ writes: > >> No, that is not what I want. I think we'd better add a comments that > >> we *DO NOT WRITE TO THAT ADDRESS*, what the manual describes is that > >> there may be some platforms which write to that address. It's not the > >> same thing. > > > >Some platforms update the timeval and some don't, so portable > >applications must simply assume that its contents are undefined after > >the select(2) call. It can not be relied on to contain either the > >initial value nor the amount of time remaining. Thus your proposed > >change is pointless. > > I disagree. The FreeBSD man pages should document the behaviour of > FreeBSD. It's all very nice stating that SUSv2 allows a system to > modify the value passed as timeout but (IMNSHO), it is more important > to document what FreeBSD actually does. > > I agree that a _portable_ application must assume that timeout will > be undefined but that's no reason for refusing to document what > FreeBSD's behaviour actually is. > > There are two situations where the actual behaviour matters: > 1) Porting a random application that assumes specific behaviour for > select(). I need to know how FreeBSD behaves to know whether I > need to patch the code or not. > 2) I'm writing code that is specifically for FreeBSD. If I know > timeout will not change, I can optimise the code to avoid having to > re-initialise timeout before each select call. > > -- > Peter Jeremy > > Yes, that is actually what I want. Without knowing about what the OS would deal with the address, maybe developers need to define two timeval struct, one for keeping the data, the other for the select() syscall. It seems ugly. Once the behavior of FreeBSD is described clearly, it's more convenient for developers to write codes cleanly and efficiently.