Date: Wed, 16 May 2007 21:05:42 +0800 From: MQ <antinvidia@gmail.com> To: freebsd-arch@freebsd.org Subject: Re: A problem with the select(2) interface Message-ID: <be0088ce0705160605n1aa0986avc312fbd575704009@mail.gmail.com> In-Reply-To: <86odknqvf3.fsf@dwp.des.no> References: <be0088ce0705140729m4c24f2cbr21f6f050aac75c89@mail.gmail.com> <86odknqvf3.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
2007/5/14, Dag-Erling Sm=F8rgrav <des@des.no>: > > MQ <antinvidia@gmail.com> writes: > > 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 timeva= l > *' > > instead? This type can inform the users explicitly that we do NOT modif= y > the > > timeval struct. But I'm not sure if this modification will conflict wit= h > the > > POSIX standard. Will you please tell me your considerations? Any > suggestions > > will be appreciated. > > According to POSIX, the struct timeval may be updated to reflect the > amount of time left if select() returns early (so you can call select() > again with the same struct timeval and hit your original deadline). In > reality, there is so much old code around that depends on it *not* being > updated that this has never been implemented. > > This is often mentioned as an example of why blindly implementing a > standard is not a good idea. > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > I'm very sorry that yesterday I replied to des only by mistake. For completeness, the mail is here. I don't think it makes to much difference if we add a `const' qualifier to the type. There are 4 types of conditions when porting the applications which use select(2): 1. from FreeBSD to an OS that doesn't modify this timeval struct 2. from FreeBSD to an OS that DO modify this timeval struct 3. from an OS that doesn't update this struct to FreeBSD 4. from an OS that update this struct to FreeBSD In circumstance 2 and circumstance 4, the programmer should always concern that the difference between the source platform and destination platform. S= o add a `const' qualifier does not affect the original codes too much. In circumstance 3, we can directly accept the codes. The addtional `const' qualifier can be simply ignored. Because the cast from a `type *' to `const type *' is acceptable. In circumstance 1, adding a `const' qualifier in our implementation may mak= e things a bit different. The addtional `const' allows a pointer variable of type `const struct timeval *' to be passed to select(2). If someone have done something like that, his code would be warned by the compiler under other platforms in which select(2) accepts only `struct timeval *'. After all, I don't think this is a real problem with the first condition. S= o is there any other reasons that we should not add the qualifier? Actually, what I was anxious about is that there is some rules that ask the committer= s to follow the standards stringently. If adjusting the type is impossible, shall we add some comments in the man page to reflect that we do not write to the address?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?be0088ce0705160605n1aa0986avc312fbd575704009>