[GRASS5] [bug #3087] (grass) high cpu usage

[Hamish]

> >> some commands, like d.zoom, d.what.rast or d.what.vect using about
> >> 50% or more of cpu resources. there is no problem with this in
> >> grass54. my cpu is pentium 4 2.8ghz.
> 
> > This is a known problem with all programs which use the mouse.
..
> Yeah, various people have complained about this, but it has been
> neither fixed nor reverted.
> 
> AFAIK, it's only required for the newer v.digit and d.what.vect, due
> to the "form" library. The problem with the original implementation
> was that the program would block while waiting for a mouse press.
> 
> A better solution would have been to leave the original (working)
> mouse handling untouched and to have implemented the "enhanced"
> version as separate operations. That way, only the programs which
> actually need the new version would cause problems.

... but that doesn't actually solve the problem, it just contains it
better.

How to more forward on this?

Do we move backwards and start from scratch with a better design for
v.digit et al. or do we try and work around the current state of
affairs? (given the resources at hand and the fact the form library
author doesn't see it as the future)

e.g., will nanosleep() be portable enough for us to use as a "good
enough" solution?


sleep() is portable  (conforms to POSIX.1)

usleep() might not be  (conforms to BSD 4.3)
  "The SUSv2 version returns int, and this is also the prototype used
  by glibc 2.2.2.  Only the EINVAL error return is documented by SUSv2."

Then we have nanosleep(), which conforms to POSIX.1b (formerly POSIX.4).

[all according to Debian's "manpages-dev" text]


Should our "POSIX compliant" goal mean POSIX.1 only or are modern
revisions to the POSIX standard ok (i.e. nanosleep())?

And what about [lib/gis/sleep.c] sleep_ltp() as a G_usleep() fn?
(unused AFAICT)



Hamish