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.
> 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
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:
for more details.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message