Re: pselect() modifying timeout
On Gwe, 2005-08-05 at 12:42 +0200, Michael Kerrisk wrote: > 1. POSIX made the behaviour of pselect() explicit -- the >timeout must not be modified. The idea was to avoid the >vagueness of the select() specification; it had to be vague >because of existing implementations. By contrast, there were Unfortunately it made the wrong choice with pselect, as Linux select experience has shown the modified timeout is *very* useful data to some applications. So the patch is better than the POSUX behaviour. The library can wrap it to provide the poorer standards compliant API while not stopping people using the better one for Linux specific apps. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pselect() modifying timeout
On Gwe, 2005-08-05 at 12:42 +0200, Michael Kerrisk wrote: 1. POSIX made the behaviour of pselect() explicit -- the timeout must not be modified. The idea was to avoid the vagueness of the select() specification; it had to be vague because of existing implementations. By contrast, there were Unfortunately it made the wrong choice with pselect, as Linux select experience has shown the modified timeout is *very* useful data to some applications. So the patch is better than the POSUX behaviour. The library can wrap it to provide the poorer standards compliant API while not stopping people using the better one for Linux specific apps. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pselect() modifying timeout
> Michael Kerrisk wrote: > > Please consider making Linux pselect() conform to POSIX on this > > point. > > There is no question the implementation will conform. But this not > dependent on changing the syscall interface. We deliberately decided to > not require the kernel interface to be different from select. The > userlevel code will take care of the difference. The kernel code is good > as proposed. Okay -- thanks for the info. Cheers, Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pselect() modifying timeout
Michael Kerrisk wrote: > Please consider making Linux pselect() conform to POSIX on this > point. There is no question the implementation will conform. But this not dependent on changing the syscall interface. We deliberately decided to not require the kernel interface to be different from select. The userlevel code will take care of the difference. The kernel code is good as proposed. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ signature.asc Description: OpenPGP digital signature
pselect() modifying timeout
Hello David, By the way, looking at the comments to the last version of the pselect()/ppoll()patch, I see that the treatment of the timeout argument is made dependent on the personality. http://marc.theaimsgroup.com/?l=linux-kernel=111883591220436=2 I'm not sure that this is a good idea; my reasons as follows: 1. POSIX made the behaviour of pselect() explicit -- the timeout must not be modified. The idea was to avoid the vagueness of the select() specification; it had to be vague because of existing implementations. By contrast, there were no pre-existing implementations when pselect() was specified. (By the way, although one or two posts in the earlier thread implied that pselect() has long/widely been present on some systems, this is almost certainly not true. The only systems where I believe it is currently implemented are two that were recently Unix 03 certified: Solaris 10 and AIX (5.3?). I know from doing quite a bit of checking that it is not present as a kernel implementation on most (all?) other systems (even though it was already described by POSIX.1g and Richard Stevens 7 years ago)) I haven't tested Solaris 10 and AIX, but I think one can be reasonably sure that they would conform to the letter of POSIX law. Lacking any strong reason to the contrary, Linux should (IMO) too (why gratuitously introduce differences across implementations?). 2. The existing (non-atomic) glibc pselect() implementation does not change the timeout argument. Please consider making Linux pselect() conform to POSIX on this point. Cheers, Michael -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pselect() modifying timeout
Hello David, By the way, looking at the comments to the last version of the pselect()/ppoll()patch, I see that the treatment of the timeout argument is made dependent on the personality. http://marc.theaimsgroup.com/?l=linux-kernelm=111883591220436w=2 I'm not sure that this is a good idea; my reasons as follows: 1. POSIX made the behaviour of pselect() explicit -- the timeout must not be modified. The idea was to avoid the vagueness of the select() specification; it had to be vague because of existing implementations. By contrast, there were no pre-existing implementations when pselect() was specified. (By the way, although one or two posts in the earlier thread implied that pselect() has long/widely been present on some systems, this is almost certainly not true. The only systems where I believe it is currently implemented are two that were recently Unix 03 certified: Solaris 10 and AIX (5.3?). I know from doing quite a bit of checking that it is not present as a kernel implementation on most (all?) other systems (even though it was already described by POSIX.1g and Richard Stevens 7 years ago)) I haven't tested Solaris 10 and AIX, but I think one can be reasonably sure that they would conform to the letter of POSIX law. Lacking any strong reason to the contrary, Linux should (IMO) too (why gratuitously introduce differences across implementations?). 2. The existing (non-atomic) glibc pselect() implementation does not change the timeout argument. Please consider making Linux pselect() conform to POSIX on this point. Cheers, Michael -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pselect() modifying timeout
Michael Kerrisk wrote: Please consider making Linux pselect() conform to POSIX on this point. There is no question the implementation will conform. But this not dependent on changing the syscall interface. We deliberately decided to not require the kernel interface to be different from select. The userlevel code will take care of the difference. The kernel code is good as proposed. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ signature.asc Description: OpenPGP digital signature
Re: pselect() modifying timeout
Michael Kerrisk wrote: Please consider making Linux pselect() conform to POSIX on this point. There is no question the implementation will conform. But this not dependent on changing the syscall interface. We deliberately decided to not require the kernel interface to be different from select. The userlevel code will take care of the difference. The kernel code is good as proposed. Okay -- thanks for the info. Cheers, Michael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
