>
> On Wed, Jul 25, 2001 at 02:12:06PM +0300, Maxim Sobolev wrote:
> > I found that the attached small program behaves very strangely when
> > linked with -pthread - it chews 100% CPU cycles while waiting in
> > select(2). This misbehaviour observed both on 5-CURRENT and 4-STABLE
> > systems. *weird*
>
> The timeout is too long. At the moment there is an arbitary limit
> on how long you can wait 'cos the kernel incorrectly uses itimerfix
> on the timeout passed to select. I have patches to improve the
> situation and I was waiting for Bruce to review them, but I've been
> using them at home for ages, so maybe I should just commit them.
> The patches only have select return an error if the timeout is too
> long to be implimented using the kernel's counters.
I am not sure that the error is what we want to get in this situation.
Perhaps more *compatible* solution would be wait indefinitely if timeout
is too large.
> > P.S. And yes, I know that I ought to use NULL instead of &tv when I
> > want to wait indefinitely in select(2), but it is how some programs
> > work.
>
> Or don't work as the case may be ;-) Posix doesn't actually require
> select to be able to deal with large wait times (I think 31 days was
> the figure I found in the SUSv2 spec). Have a look at:
>
> http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18909
>
> for more details.
Interesting, but this isn't really relevant to my question. I want to
know why the program in question behaves difefrently when linked with
and without -pthead flag (bug in libc_r?). Also [EINVAL] is not what
I'm seeing here, because as you can easily check in my test case
tv.tv_sec == 4294976, which is less that 1000000000 - upper limit of
our select(2) implementation depicted in PR 18909.
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
