[Xastir-Dev] CPU still too busy for the wrong reasons

[Curt Mills, WE7U]

On Fri, 28 Nov 2003, Henk de Groot wrote:

> If it is system-time then you have to find the systemcall that is causing 
> it. If the systemcall itself doesn't have a timeout on its own, I suggest 
> to insert a usleep() call in the loop to slow the loop down. "usleep" may 
> not be available on every flavour of unix/windows or may be mapped to a 10 
> ms timer in which case a usleep(1000) (1 ms) is rounded to zero... If you 
> are not in a hurry, like reconnecting interfaces, its safer to go with an 
> ordinary sleep(1) call.

As I recall, the sleep() call doesn't handle threading, so it's out.
If you call it, it stops all threads, not just the one you're on.
usleep() works.


> The results may vary, unfortunately "libc" of a genuine Unix(tm) doesn't 
> have a finer timeout than the 1 second sleep, unless you use a tty 
> interface to create a 100ms timeout (since VTIME is in deci-seconds).

Actually, there is a finer sleep in standard unix.  It's a trick using
select().  We use it in Xastir here and there I think.  You can get
very small time intervals using it.


> Of course the real solution is to use blocking systemcalls and have these 
> things run in a separate thread. I believe Xastir does this most (all?) of 
> the time. Still even then the system call may have an answer instantly 
> causeing it to return without delay, which will cause the same problem if 
> that happens in a loop.

Check main.c:UpdateTime().  We have that routine schedule itself to
run again after a very short time period.  Perhaps on FreeBSD it
behaves poorly.

-- 
Curt, WE7U.				archer at eskimo.com
http://www.eskimo.com/~archer
  Lotto:  A tax on people who are bad at math. - unknown
Windows:  Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me:  I picked the coordinate system!"