>the limit (well, without testing :-) ). If it was woken up after a couple
>hours, it could easily recover: just check the current time - in most
>cases it will do that anyway. The "-1" in my patch makes _really_ sure we
>have no collision with "eternity" (in case someone changes the definition
>of MAX_SELECT_SECOND). Linus?
I understand your point but remember that we are talking about 497 day of
delay that will be exchanged with "eternity". Arch that uses HZ > 100 has
a 64bit jiffies.
>Andrea, here are some comments on your original patch, for the record:
Thanks.
>like that. It's not the upper bound on the timeout. "Eternity" is a
>special case. It's probably better to leave it clearly separated from the
>range of valid values. The same way open() returns -1 on error: -1 is not
>a valid FD (which is, in realistic settings, an unsigned short). Same
>trick for getchar(). The rest depends on the exact semantics you want for
>select(), as I explained above.
Personally I see more safe to stall forever than returning before the
expected time. This is always been my feeling as you can see from
schedule_timeout().
>One more comment on your patch: Generally speaking, this style of checking
>overflows _after_ they happen makes me a little nervous. It works in many
>cases, like what you do: "a+b". If you're doing "a+b+c", testing things
>like the sign of the result doesn't catch all overflows; nor if you have
>multiplications. So a seemingly innocent change made later on could break
>the test: a case of bad "bug locality".
I can add a comment but I don' t care too much about this issue. Following
this thought we should not write kernel code at all ;). Everything can be
screwed up by a mistake from somebody like me ;>>.
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/