Date: Thu, 17 May 2007 07:46:49 -0400 From: Gary Palmer <gpalmer@freebsd.org> To: MQ <antinvidia@gmail.com> Cc: freebsd-arch@freebsd.org Subject: Re: A problem with the select(2) interface Message-ID: <20070517114649.GE28958@in-addr.com> In-Reply-To: <be0088ce0705170409p48f48685rab91537c00019018@mail.gmail.com> References: <be0088ce0705140729m4c24f2cbr21f6f050aac75c89@mail.gmail.com> <86odknqvf3.fsf@dwp.des.no> <be0088ce0705150025q3a589369ib20d03cfe5de1520@mail.gmail.com> <86wszah2ua.fsf@dwp.des.no> <be0088ce0705160559y4c312c7aqcc45cdd81f8f0323@mail.gmail.com> <86fy5wkim5.fsf@dwp.des.no> <20070517094445.GD1149@turion.vk2pj.dyndns.org> <be0088ce0705170409p48f48685rab91537c00019018@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 17, 2007 at 07:09:19PM +0800, MQ wrote: > 2007/5/17, Peter Jeremy <peterjeremy@optushome.com.au>: > > > >On 2007-May-16 15:23:14 +0200, Dag-Erling Smrgrav <des@des.no> wrote: > >>MQ <antinvidia@gmail.com> 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. And if we change the behaviour tomorrow your code breaks in really interesting and probably difficult to debug ways. Code with the assumption that the timeval struct will change and you'll be much safer. If we do document the behaviour, while it will help address point (1) above it will also encourage bad coding practices. As such, I'm on the fence in this discussion - both sides have merit. In either case, this is a bikeshed discussion at this point. Can we please bring this discussion to a conclusion so we can go fix the nuclear reactor instead.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070517114649.GE28958>