Date: Thu, 17 May 2007 12:44:14 +0200 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: MQ <antinvidia@gmail.com>, freebsd-arch@freebsd.org Subject: Re: A problem with the select(2) interface Message-ID: <86ps4zu3up.fsf@dwp.des.no> In-Reply-To: <20070517094445.GD1149@turion.vk2pj.dyndns.org> (Peter Jeremy's message of "Thu\, 17 May 2007 19\:44\:45 %2B1000") 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy <peterjeremy@optushome.com.au> writes: > 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. Easy: patch the code to not assume anything about the contents of the struct timeval after select(2) returns. > 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. OK, I'll bite. If you can show me that you were actually able to measure the difference in performance between code that reinitializes the timeout every time and code that doesn't, I'll commit your patch. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86ps4zu3up.fsf>