this bug's URL: http://intevation.de/rt/webrt?serial_num=3087
-------------------------------------------------------------------------
Subject: high cpu usage
Platform: GNU/Linux/i386
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: 6.0.0
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.
best,
maciek
-------------------------------------------- Managed by Request Tracker
Request Tracker wrote:
this bug's URL: http://intevation.de/rt/webrt?serial_num=3087
Subject: high cpu usage
GRASS Version: 6.0.0
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.
Essentially, to prevent the program from pausing until a mouse button
is pressed, the code (libraster) polls for mouse events in a busy-wait
rather than blocking until a mouse event is received (as was the case
in 5.4 and earlier).
--
Glynn Clements <glynn@gclements.plus.com>
From: "Glynn Clements" <glynn@gclements.plus.com>
To: "Request Tracker" <grass-bugs@intevation.de>
Cc: <grass5@grass.itc.it>
Sent: Monday, March 14, 2005 1:05 AM
Subject: Re: [GRASS5] [bug #3087] (grass) high cpu usage
this bug's URL: http://intevation.de/rt/webrt?serial_num=3087
Subject: high cpu usage
GRASS Version: 6.0.0
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.
But a very serious one and requiring a fix if possible.
I'm not the one who reported on this (that was another Maciek 
) so I
might not remember details, but as far as I know them guys use this machine
(P4 2.8 GHz, 4GB RAM) as a server for 12 Linux stations during GIS/Grass
classes and courses at the Wroclaw University. And when few users use any
d.* simultanously command on Grass6 it causes a complete deadlock of the
server and the only solution is to reset it. Which makes students, Grass
newbies in most, doubt in Grass quality.
Essentially, to prevent the program from pausing until a mouse button
is pressed, the code (libraster) polls for mouse events in a busy-wait
rather than blocking until a mouse event is received (as was the case
in 5.4 and earlier).
Due to this they still stick to Grass 5.4 in spite of 6.0 being such a great
and advanced software.
Maciek Sieczka
Maciek Sieczka wrote:
>> this bug's URL: http://intevation.de/rt/webrt?serial_num=3087
>
>> Subject: high cpu usage
>
>> GRASS Version: 6.0.0
>>
>> 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.
But a very serious one and requiring a fix if possible.
I'm not the one who reported on this (that was another Maciek ) so I
might not remember details, but as far as I know them guys use this machine
(P4 2.8 GHz, 4GB RAM) as a server for 12 Linux stations during GIS/Grass
classes and courses at the Wroclaw University. And when few users use any
d.* simultanously command on Grass6 it causes a complete deadlock of the
server and the only solution is to reset it. Which makes students, Grass
newbies in most, doubt in Grass quality.
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.
--
Glynn Clements <glynn@gclements.plus.com>