This is probably not related to the last couple of posts on v.digit
crashing... but it seems like a lot of the interactive programs like v.digit
will send my processor useage up to near 100% when it is waiting for user
input...
Any ideas?
--
Dylan Beaudette
Soil Science Graduate Group
University of California at Davis
This is probably not related to the last couple of posts on v.digit
crashing... but it seems like a lot of the interactive programs like
v.digit will send my processor useage up to near 100% when it is
waiting for user input...Any ideas?
yeah.. the code which waits for you to press a mouse button is a loop.
Usually you would have it sleep for a tenth of a second between
checking, but the usleep() function in the C library isn't portable
across all the computing platforms that GRASS supports.
There is one called sleep() which will work on everyones' systems, but
it will only let the system go to sleep for 1 second at a time which
makes reaction time way too slow. So we just leave it checking as fast
as the computer can check, which is why you are pegged at 100%.
annoying but harmless for the most part.
Note that d.zoom from the command line in 5.3 is fine, in 5.7 it is not.
5.7's d.what.vect is especially bad at this.
This is even worse when you are running grass remotely over the network.
suggestions for fixing this are welcome..
Hamish
Hamish wrote:
> This is probably not related to the last couple of posts on v.digit
> crashing... but it seems like a lot of the interactive programs like
> v.digit will send my processor useage up to near 100% when it is
> waiting for user input...
>
> Any ideas?yeah.. the code which waits for you to press a mouse button is a loop.
Usually you would have it sleep for a tenth of a second between
checking, but the usleep() function in the C library isn't portable
across all the computing platforms that GRASS supports.There is one called sleep() which will work on everyones' systems, but
it will only let the system go to sleep for 1 second at a time which
makes reaction time way too slow. So we just leave it checking as fast
as the computer can check, which is why you are pegged at 100%.annoying but harmless for the most part.
Note that d.zoom from the command line in 5.3 is fine, in 5.7 it is not.
5.7's d.what.vect is especially bad at this.This is even worse when you are running grass remotely over the network.
suggestions for fixing this are welcome..
Use select() on both the X connection and the monitor socket. See
Get_Xevent() in Serve_Xevent.c.
--
Glynn Clements <glynn@gclements.plus.com>
On Friday 12 November 2004 03:46 am, you wrote:
Hamish wrote:
> > This is probably not related to the last couple of posts on v.digit
> > crashing... but it seems like a lot of the interactive programs like
> > v.digit will send my processor useage up to near 100% when it is
> > waiting for user input...
> >
> > Any ideas?
>
> yeah.. the code which waits for you to press a mouse button is a loop.
> Usually you would have it sleep for a tenth of a second between
> checking, but the usleep() function in the C library isn't portable
> across all the computing platforms that GRASS supports.
>
> There is one called sleep() which will work on everyones' systems, but
> it will only let the system go to sleep for 1 second at a time which
> makes reaction time way too slow. So we just leave it checking as fast
> as the computer can check, which is why you are pegged at 100%.
>
> annoying but harmless for the most part.
>
> Note that d.zoom from the command line in 5.3 is fine, in 5.7 it is not.
> 5.7's d.what.vect is especially bad at this.
>
> This is even worse when you are running grass remotely over the network.
>
>
> suggestions for fixing this are welcome..Use select() on both the X connection and the monitor socket. See
Get_Xevent() in Serve_Xevent.c.
Would this be all that it would take to fix the 100% CPU load while waiting
for input? If I had the skills to implement this I would... but alas. It sure
would be nice to not have GRASS pegging my CPU at 100% for simple
operations...
--
Dylan Beaudette
Soil Science Graduate Group
University of California at Davis
Dylan Beaudette wrote:
> > > This is probably not related to the last couple of posts on v.digit
> > > crashing... but it seems like a lot of the interactive programs like
> > > v.digit will send my processor useage up to near 100% when it is
> > > waiting for user input...
> > >
> > > Any ideas?
> >
> > yeah.. the code which waits for you to press a mouse button is a loop.
> > Usually you would have it sleep for a tenth of a second between
> > checking, but the usleep() function in the C library isn't portable
> > across all the computing platforms that GRASS supports.
> >
> > There is one called sleep() which will work on everyones' systems, but
> > it will only let the system go to sleep for 1 second at a time which
> > makes reaction time way too slow. So we just leave it checking as fast
> > as the computer can check, which is why you are pegged at 100%.
> >
> > annoying but harmless for the most part.
> >
> > Note that d.zoom from the command line in 5.3 is fine, in 5.7 it is not.
> > 5.7's d.what.vect is especially bad at this.
> >
> > This is even worse when you are running grass remotely over the network.
> >
> >
> > suggestions for fixing this are welcome..
>
> Use select() on both the X connection and the monitor socket. See
> Get_Xevent() in Serve_Xevent.c.Would this be all that it would take to fix the 100% CPU load while waiting
for input?
Actually, I've realised that it isn't that simple. AFAIK, the reason
why the changes were made to the mouse handling was so that events
from the driver could be interleaved with events from other sources.
Unfortunately, the driver doesn't have access to those other sources,
so it can't make any allowance for them.
The simpler cases (e.g. d.what.rast etc) can be fixed (by reverting to
the original code), but the cases which rely upon the new behaviour
(primarily v.digit) can't be fixed so easily.
--
Glynn Clements <glynn@gclements.plus.com>