[GRASSLIST:4822] Re: v.digit and other interactive commands

[Glynn Clements]

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 at gclements.plus.com>