Wed, Dec 1 2004
06:43:25
|
|
Request created by jidanni@jidanni.org
|
|
Return-Path |
<jidanni@jidanni.org>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
To |
grass-bugs@intevation.de
|
Subject |
nowadays tight loop while waiting for mouse input
|
From |
Dan Jacobson <jidanni@jidanni.org>
|
Date |
Wed, 01 Dec 2004 12:26:11 +0800
|
Message-ID |
<87k6s2wsnw.fsf@jidanni.org>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
Nowadays when programs are waiting for mouse input, they go into tight
loops, as seen with strace here on d.where:
write(4, "\0\0\0\0", 4) = 4
read(5, "@\1\0\0", 4) = 4
read(5, "\357\0\0\0", 4) = 4
read(5, "\0\0\0\0", 4) = 4
$ strace v.what.vect ...
read(9, "\0\0\0\0", 4) = 4
write(8, "\0\0\0\0", 4) = 4
read(9, "@\1\0\0", 4) = 4
v.digit too.
While the program is waiting for the user to do something, the CPU
meter stays pegged at 100%. Debian grass 5.7.0-4
|
|
Wed, Dec 1 2004
09:40:10
|
|
Mail sent by neteler@itc.it
|
|
Return-Path |
<neteler@itc.it>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Wed, 1 Dec 2004 09:41:46 +0100
|
From |
Markus Neteler <neteler@itc.it>
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #2746] (grass) nowadays tight loop while waiting for mouse input
|
Message-ID |
<20041201084146.GE12879@thuille.itc.it>
|
Mail-Followup-To |
Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
|
References |
<20041201054325.D4051102BEC@lists.intevation.de>
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Disposition |
inline
|
In-Reply-To |
<20041201054325.D4051102BEC@lists.intevation.de>
|
User-Agent |
Mutt/1.4.1i
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
On Wed, Dec 01, 2004 at 06:43:25AM +0100, Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=2746
> -------------------------------------------------------------------------
>
> Nowadays when programs are waiting for mouse input, they go into tight
> loops, as seen with strace here on d.where:
> write(4, "\0\0\0\0", 4) = 4
> read(5, "@\1\0\0", 4) = 4
> read(5, "\357\0\0\0", 4) = 4
> read(5, "\0\0\0\0", 4) = 4
> $ strace v.what.vect ...
> read(9, "\0\0\0\0", 4) = 4
> write(8, "\0\0\0\0", 4) = 4
> read(9, "@\1\0\0", 4) = 4
> v.digit too.
> While the program is waiting for the user to do something, the CPU
> meter stays pegged at 100%. Debian grass 5.7.0-4
This is due to the implementation of mouse input (which differs
from older GRASS versions).
Markus
|
|
Wed, Dec 1 2004
09:40:23
|
|
Status changed to resolved by mneteler
|
|
Fri, Dec 3 2004
05:07:55
|
|
Mail sent by jidanni@jidanni.org
|
|
Return-Path |
<jidanni@jidanni.org>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
To |
Markus Neteler via RT <grass-bugs@intevation.de>
|
Subject |
Re: [bug #2746] (grass) nowadays tight loop while waiting for mouse input
|
References |
<20041201084010.760D9102BDB@lists.intevation.de>
|
From |
Dan Jacobson <jidanni@jidanni.org>
|
Date |
Fri, 03 Dec 2004 07:53:29 +0800
|
Message-ID |
<87oehcuuiu.fsf@jidanni.org>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
X-Spam-Status |
No, hits=-4.5 tagged_above=-999.0 required=3.0 tests=BAYES_00, DATE_IN_PAST_03_06
|
X-Spam-Level |
|
>> While the program is waiting for the user to do something, the CPU
>> meter stays pegged at 100%. Debian grass 5.7.0-4
H> This is due to the implementation of mouse input (which differs
H> from older GRASS versions).
Well isn't that unacceptable!?!? What other program dares to crank the
CPU to 100% while waiting for mouse input? What if mozilla did that,
or even bash!?! Sounds crazy to me. OK, if doing a flight simulation,
but you're not. You are only waiting for input. Nope, bad!
|
|
Fri, Dec 3 2004
05:07:55
|
|
Status changed to open by _rt_system
|
|
Sat, Mar 12 2005
15:23:38
|
|
Request created by guest (as #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 |
|
Mon, Mar 14 2005
01:05:15
|
|
Mail sent by glynn@gclements.plus.com (as #3087)
|
|
Return-Path |
<glynn@gclements.plus.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn@gclements.plus.com>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<16948.54578.164334.567941@gargle.gargle.HOWL>
|
Date |
Mon, 14 Mar 2005 00:05:06 +0000
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #3087] (grass) high cpu usage
|
In-Reply-To |
<20050312142338.A10FF1006BE@lists.intevation.de>
|
References |
<20050312142338.A10FF1006BE@lists.intevation.de>
|
X-Mailer |
VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
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>
|
|
Mon, Mar 14 2005
17:26:24
|
|
Mail sent by turek2@poczta.fm (as #3087)
|
|
Return-Path |
<turek2@poczta.fm>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Message-ID |
<4235BB25.7000202@poczta.fm>
|
Date |
Mon, 14 Mar 2005 17:26:13 +0100
|
From |
turek2 <turek2@poczta.fm>
|
User-Agent |
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
|
X-Accept-Language |
en-us, en
|
MIME-Version |
1.0
|
To |
Glynn Clements via RT <grass-bugs@intevation.de>
|
Subject |
Re: [bug #3087] (grass) high cpu usage
|
References |
<20050314000515.D65861006BD@lists.intevation.de>
|
In-Reply-To |
<20050314000515.D65861006BD@lists.intevation.de>
|
Content-Type |
text/html; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
X-EMID |
e5f48138
|
X-Spam-Status |
No, hits=-4.4 tagged_above=-999.0 required=3.0 tests=BAYES_00, HTML_MESSAGE, HTML_TITLE_EMPTY, MIME_HTML_ONLY
|
X-Spam-Level |
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Glynn Clements via RT wrote:
<blockquote cite="mid20050314000515.D65861006BD@lists.intevation.de"
type="cite">
<pre wrap="">Request Tracker wrote:
</pre>
<blockquote type="cite">
<pre wrap="">this bug's URL: <a class="moz-txt-link-freetext" href="http://intevation.de/rt/webr
t?serial_num=3087">http://intevation.de/rt/webrt?serial_num=3087</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">Subject: high cpu usage
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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).
</pre>
</blockquote>
is there any way to resolve this problem? we are running workshop and
we planned to do some vector based analysis using grass6. now our
server stops when a few persons are using d.* commands.<br>
</body>
</html>
<TABLE cellPadding="3" bgColor="#ffffff"><TBODY><TR><TD style="font: 12px Courier
New, Courier, monotype.com; padding: 3px; background: #ffffff; color: #000000">---------------------
-------------------------------------------------
<BR>
Szwajcar Polakowi wilkiem?!? >>> <A href="http://link.interia.pl/f1864">http://link.interia
.pl/f1864</a></TD></TR></TBODY></TABLE>
|
|
Mon, Mar 14 2005
17:27:55
|
|
Comments added by guest (as #3087)
|
|
Cc: turek2@poczta.fm
sorry for my previous message in html format.
is there any way to resolve this problem? we are running workshop and
we planned to do some vector based analysis using grass6. now our
server stops when a few persons are using d.* |
|
Tue, Mar 15 2005
20:21:48
|
|
Comments added by guest (as #3087)
|
|
Cc: turek2@poczta.fm
it seems that grass6 is, because of this "little thing", rather useless in
multiaccess environment. its not possible to run grass6 by more than one
person at the same time because it hangs up the server (deadlock?) |
|
Sat, Mar 19 2005
10:50:50
|
|
Mail sent by werchowyna@epf.pl (as #3087)
|
|
Return-Path |
<werchowyna@epf.pl>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Message-ID |
<01a001c52c69$3f5488a0$69c61d3e@eustahiush>
|
From |
"Maciek Sieczka" <werchowyna@epf.pl>
|
To |
"Glynn Clements" <glynn@gclements.plus.com>, "Request Tracker" <grass-bugs@intevation.de>
|
Cc |
"grass devel" <grass5@grass.itc.it>, "turek2" <turek2@poczta.fm>, "Pawel Netzel" <netzel@meteo.uni.wroc.pl>
|
References |
<20050312142338.A10FF1006BE@lists.intevation.de> <16948.54578.164334.567941@gargle.gargle.HOWL>
|
Subject |
Re: [GRASS5] [bug #3087] (grass) high cpu usage
|
Date |
Sat, 19 Mar 2005 10:46:36 +0100
|
MIME-Version |
1.0
|
Content-Type |
text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
|
Content-Transfer-Encoding |
7bit
|
X-Priority |
3
|
X-MSMail-Priority |
Normal
|
X-Mailer |
Microsoft Outlook Express 6.00.2900.2180
|
X-MimeOLE |
Produced By Microsoft MimeOLE V6.00.2900.2180
|
X-Antivirus |
avast! (VPS 0511-1, 2005-03-17), Outbound message
|
X-Antivirus-Status |
Clean
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
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
|
|
Sat, Mar 19 2005
16:45:01
|
|
Mail sent by glynn@gclements.plus.com (as #3087)
|
|
Return-Path |
<glynn@gclements.plus.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn@gclements.plus.com>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<16956.18673.938681.528484@gargle.gargle.HOWL>
|
Date |
Sat, 19 Mar 2005 15:44:49 +0000
|
To |
"Maciek Sieczka" <werchowyna@epf.pl>
|
Cc |
"Request Tracker" <grass-bugs@intevation.de>, "grass devel" <grass5@grass.itc.it>, "turek2" <turek2@poczta.fm>, "Pawel Netzel" <netzel@meteo.uni.wroc.pl>
|
Subject |
Re: [GRASS5] [bug #3087] (grass) high cpu usage
|
In-Reply-To |
<01a001c52c69$3f5488a0$69c61d3e@eustahiush>
|
References |
<20050312142338.A10FF1006BE@lists.intevation.de> <16948.54578.164334.567941@gargle.gargle.HOWL> <01a001c52c69$3f5488a0$69c61d3e@eustahiush>
|
X-Mailer |
VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
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>
|
|
Sun, Apr 3 2005
08:52:15
|
|
Mail sent by hamish_nospam@yahoo.com (as #3087)
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Sun, 3 Apr 2005 18:51:55 +1200
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
glynn@gclements.plus.com
|
Cc |
grass-bugs@intevation.de, grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #3087] (grass) high cpu usage
|
Message-Id |
<20050403185155.6b4cebb0.hamish_nospam@yahoo.com>
|
X-Mailer |
Sylpheed version 1.0.3 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
|
X-Spam-Level |
|
> >> 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
|
|
Mon, Apr 4 2005
05:33:41
|
|
Mail sent by glynn@gclements.plus.com (as #3087)
|
|
Return-Path |
<glynn@gclements.plus.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn@gclements.plus.com>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<16976.46476.175695.505290@gargle.gargle.HOWL>
|
Date |
Mon, 4 Apr 2005 04:33:32 +0100
|
To |
Hamish <hamish_nospam@yahoo.com>
|
Cc |
grass-bugs@intevation.de, grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #3087] (grass) high cpu usage
|
In-Reply-To |
<20050403185155.6b4cebb0.hamish_nospam@yahoo.com>
|
References |
<20050403185155.6b4cebb0.hamish_nospam@yahoo.com>
|
X-Mailer |
VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
Hamish wrote:
> > >> 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)
1. Make v.digit a standalone program which doesn't use XDRIVER.
2. Remove the form support from d.what.vect.
3. Revert the R_get_location_with_* to their original forms.
The display driver API is inherently unsuitable for programs which
need to multiplex mouse input with other input sources.
--
Glynn Clements <glynn@gclements.plus.com>
|
|
Mon, Oct 10 2005
16:10:05
|
|
Area changed to grass6 by msieczka
|
|
Mon, Apr 24 2006
05:18:35
|
|
Comments added by guest (as #3087)
|
|
This appears to be fixed by Radim c. Mar 21 2006.
Modules using the TclTk form lib still show it (d.what.vect, v.digit, ...).
Hamish
|
|
Mon, Apr 24 2006
05:19:07
|
|
Subject changed to high cpu usage on mouse ops by hbowman (as #3087)
|
|
Wed, Apr 26 2006
21:30:08
|
|
Mail sent by msieczka (as #3087)
|
|
Hamish wrote:
> Modules using the TclTk form lib still show it (d.what.vect, v.digit, ...).
Absolutelly true, but thanks to the respective fix in X11 displays the CPU
usage has become low enough for v.digit and d.what.vect in form mode (eg.
called from d.m) to be really interactive and usable now. Having said that, it
doens't mean form mode is really fixed, only it is not painfull now. Not sure
how it works in remote case though - can you check and report back?
Maciek
|
|
Thu, Jun 22 2006
20:51:15
|
|
Mail sent by msieczka (as #3087)
|
|
Hi,
This bug's URL:
http://intevation.de/rt/webrt?serial_num=3087
The bug seems to be fixed for me. Anybody minds closing it?
Maciek
|
|
Fri, Jun 23 2006
02:09:04
|
|
Mail sent by hamish_nospam@yahoo.com (as #3087)
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Fri, 23 Jun 2006 12:08:55 +1200
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Maciek Sieczka via RT <grass-bugs@intevation.de>
|
Cc |
grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-user] [bug #3087] (grass) high cpu usage on mouse ops
|
Message-Id |
<20060623120855.72acb2be.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20060622185115.D97CE101EF6@lists.intevation.de>
|
References |
<20060622185115.D97CE101EF6@lists.intevation.de>
|
X-Mailer |
Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
|
X-Spam-Level |
|
Maciek via RT wrote:
> This bug's URL:
> http://intevation.de/rt/webrt?serial_num=3087
>
> The bug seems to be fixed for me. Anybody minds closing it?
The bug still exists in v.digit only, e.g. when you open the "settings"
form.
also I think it will turn up on systems that don't have nanosleep(), ie
systems that are not POSIX.1b (formerly POSIX.4) compliant. I have no
idea which if any systems won't be.
Hamish
|
|
Fri, Jun 23 2006
08:43:43
|
|
Mail sent by neteler@itc.it (as #3087)
|
|
Return-Path |
<neteler@itc.it>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Message-ID |
<449B8D9C.2050603@itc.it>
|
Date |
Fri, 23 Jun 2006 08:43:40 +0200
|
From |
Markus Neteler <neteler@itc.it>
|
User-Agent |
Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929)
|
X-Accept-Language |
en-us, en
|
MIME-Version |
1.0
|
To |
Hamish <hamish_nospam@yahoo.com>
|
Cc |
Maciek Sieczka via RT <grass-bugs@intevation.de>, grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] Re: [GRASS-user] [bug #3087] (grass) high cpu usage on mouse ops
|
References |
<20060622185115.D97CE101EF6@lists.intevation.de> <20060623120855.72acb2be.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20060623120855.72acb2be.hamish_nospam@yahoo.com>
|
X-Enigmail-Version |
0.93.0.0
|
OpenPGP |
url=http://mpa.itc.it/markus/markus_gpgkey.asc
|
Content-Type |
text/plain; charset=ISO-8859-1
|
Content-Transfer-Encoding |
7bit
|
X-OriginalArrivalTime |
23 Jun 2006 06:43:40.0311 (UTC) FILETIME=[5CCE2A70:01C69690]
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
Hamish wrote on 06/23/2006 02:08 AM:
>Maciek via RT wrote:
>
>
>
>>This bug's URL:
>>http://intevation.de/rt/webrt?serial_num=3087
>>
>>The bug seems to be fixed for me. Anybody minds closing it?
>>
>>
>
>
>The bug still exists in v.digit only, e.g. when you open the "settings"
>form.
>
>also I think it will turn up on systems that don't have nanosleep(), ie
>systems that are not POSIX.1b (formerly POSIX.4) compliant. I have no
>idea which if any systems won't be.
>
>
GDAL does in configure.in:
dnl Needed on Solaris.
AC_CHECK_LIB(rt,nanosleep,,,)
while GRASS does:
AC_CHECK_FUNCS(nanosleep)
Does the difference matter?
Markus
|
|
Fri, Jun 23 2006
11:07:52
|
|
Mail sent by glynn@gclements.plus.com (as #3087)
|
|
Return-Path |
<glynn@gclements.plus.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn@gclements.plus.com>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<17563.44892.563763.839671@cerise.gclements.plus.com>
|
Date |
Fri, 23 Jun 2006 10:07:40 +0100
|
To |
Markus Neteler <neteler@itc.it>
|
Cc |
Hamish <hamish_nospam@yahoo.com>, Maciek Sieczka via RT <grass-bugs@intevation.de>, grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] Re: [GRASS-user] [bug #3087] (grass) high cpu usage on mouse ops
|
In-Reply-To |
<449B8D9C.2050603@itc.it>
|
References |
<20060622185115.D97CE101EF6@lists.intevation.de> <20060623120855.72acb2be.hamish_nospam@yahoo.com> <449B8D9C.2050603@itc.it>
|
X-Mailer |
VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
Markus Neteler wrote:
> >>This bug's URL:
> >>http://intevation.de/rt/webrt?serial_num=3087
> >>
> >>The bug seems to be fixed for me. Anybody minds closing it?
> >>
> >>
> >
> >
> >The bug still exists in v.digit only, e.g. when you open the "settings"
> >form.
> >
> >also I think it will turn up on systems that don't have nanosleep(), ie
> >systems that are not POSIX.1b (formerly POSIX.4) compliant. I have no
> >idea which if any systems won't be.
> >
> >
>
> GDAL does in configure.in:
> dnl Needed on Solaris.
> AC_CHECK_LIB(rt,nanosleep,,,)
>
> while GRASS does:
> AC_CHECK_FUNCS(nanosleep)
>
> Does the difference matter?
The former checks whether nanosleep() is available when linking
against librt, while the latter checks whether it is available without
linking against additional libraries.
The former approach should only be used if the latter fails, so that
you don't link against librt if it isn't necessary.
One portable method to sleep for a fraction of a second is to use
select() with all descriptor sets NULL, e.g.:
struct timeval tv;
tv.tv_sec = 0;
tv.tv_usec = 500000;
retval = select(0, NULL, NULL, NULL, &tv);
--
Glynn Clements <glynn@gclements.plus.com>
|
|
Fri, Jun 23 2006
16:19:21
|
|
Mail sent by neteler@itc.it (as #3087)
|
|
Return-Path |
<neteler@itc.it>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Fri, 23 Jun 2006 16:19:15 +0200
|
From |
Markus Neteler <neteler@itc.it>
|
To |
Glynn Clements <glynn@gclements.plus.com>
|
Cc |
Maciek Sieczka via RT <grass-bugs@intevation.de>, grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] Re: [GRASS-user] [bug #3087] (grass) high cpu usage on mouse ops
|
Message-ID |
<20060623141915.GI28533@bartok.itc.it>
|
Mail-Followup-To |
Glynn Clements <glynn@gclements.plus.com>, Maciek Sieczka via RT <grass-bugs@intevation.de>, grass-dev@grass.itc.it
|
References |
<20060622185115.D97CE101EF6@lists.intevation.de> <20060623120855.72acb2be.hamish_nospam@yahoo.com> <449B8D9C.2050603@itc.it> <17563.44892.563763.839671@cerise.gclements.plus.com>
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Disposition |
inline
|
In-Reply-To |
<17563.44892.563763.839671@cerise.gclements.plus.com>
|
X-PGP-Key |
http://www.gdf-hannover.de/neteler/markus_gpgkey.asc
|
X-PGP-Fingerprint |
D4D5 2F80 120E AD60 E2F6 2297 21B3 D02B E1E7 E789
|
User-Agent |
Mutt/1.5.11
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
On Fri, Jun 23, 2006 at 10:07:40AM +0100, Glynn Clements wrote:
> Markus Neteler wrote:
> > >>This bug's URL:
> > >>http://intevation.de/rt/webrt?serial_num=3087
> > >>
...
>
> One portable method to sleep for a fraction of a second is to use
> select() with all descriptor sets NULL, e.g.:
>
> struct timeval tv;
>
> tv.tv_sec = 0;
> tv.tv_usec = 500000;
>
> retval = select(0, NULL, NULL, NULL, &tv);
Surprising question:
Do we want to turn this somehow into a G_nanosleep()?
Markus
|
|
Fri, Jun 23 2006
22:49:10
|
|
Mail sent by werchowyna@epf.pl (as #3087)
|
|
Return-Path |
<werchowyna@epf.pl>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Fri, 23 Jun 2006 22:39:19 +0200
|
From |
Maciek Sieczka <werchowyna@epf.pl>
|
To |
Hamish <hamish_nospam@yahoo.com>
|
Cc |
grass-bugs@intevation.de, grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] Re: [GRASS-user] [bug #3087] (grass) high cpu usage on mouse ops
|
Message-Id |
<20060623223919.2214d8bc.werchowyna@epf.pl>
|
In-Reply-To |
<20060623120855.72acb2be.hamish_nospam@yahoo.com>
|
References |
<20060622185115.D97CE101EF6@lists.intevation.de> <20060623120855.72acb2be.hamish_nospam@yahoo.com>
|
X-Mailer |
Sylpheed version 2.1.1 (GTK+ 2.8.6; i486-pc-linux-gnu)
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-3.311 tagged_above=-999 required=4 tests=[AWL=1.638, BAYES_00=-5, RCVD_BY_IP=0.051]
|
X-Spam-Level |
|
On Fri, 23 Jun 2006 12:08:55 +1200
Hamish <hamish_nospam@yahoo.com> wrote:
> Maciek via RT wrote:
>
> > This bug's URL:
> > http://intevation.de/rt/webrt?serial_num=3087
> >
> > The bug seems to be fixed for me. Anybody minds closing it?
>
>
> The bug still exists in v.digit only, e.g. when you open the
> "settings" form.
Just tried it on 6.1 CVS 2006-06-19, Ubuntu Breezy, tcl/tk 8.4 - *no*
freeze or high CPU usage after entering "Settings" form. Can you
confirm please?
Maciek
------------------------------------------------------------------------
CIEP?E KRAJE - CIEP?E MORZA. Szukasz atrakcyjnego wypoczynku w przyst?pnej cenie,
zapoznaj si? z nasz? ofert?.
ZAPRASZAMY
www.skarpatravel.pl
|
|
Fri, Jun 23 2006
23:18:14
|
|
Mail sent by werchowyna@epf.pl (as #3087)
|
|
Return-Path |
<werchowyna@epf.pl>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Fri, 23 Jun 2006 23:03:42 +0200
|
From |
Maciek Sieczka <werchowyna@epf.pl>
|
To |
hamish_nospam@yahoo.com
|
Cc |
grass-bugs@intevation.de, grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] Re: [GRASS-user] [bug #3087] (grass) high cpu usage on mouse ops
|
Message-Id |
<20060623230342.62291a64.werchowyna@epf.pl>
|
In-Reply-To |
<20060623223919.2214d8bc.werchowyna@epf.pl>
|
References |
<20060622185115.D97CE101EF6@lists.intevation.de> <20060623120855.72acb2be.hamish_nospam@yahoo.com> <20060623223919.2214d8bc.werchowyna@epf.pl>
|
X-Mailer |
Sylpheed version 2.1.1 (GTK+ 2.8.6; i486-pc-linux-gnu)
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-3.333 tagged_above=-999 required=4 tests=[AWL=1.616, BAYES_00=-5, RCVD_BY_IP=0.051]
|
X-Spam-Level |
|
On Fri, 23 Jun 2006 22:39:19 +0200
Maciek Sieczka <werchowyna@epf.pl> wrote:
> On Fri, 23 Jun 2006 12:08:55 +1200
> Hamish <hamish_nospam@yahoo.com> wrote:
>
> > Maciek via RT wrote:
> >
> > > This bug's URL:
> > > http://intevation.de/rt/webrt?serial_num=3087
> > >
> > > The bug seems to be fixed for me. Anybody minds closing it?
> >
> >
> > The bug still exists in v.digit only, e.g. when you open the
> > "settings" form.
>
> Just tried it on 6.1 CVS 2006-06-19, Ubuntu Breezy, tcl/tk 8.4 - *no*
> freeze or high CPU usage after entering "Settings" form. Can you
> confirm please?
Oopsy. Just got v.digit freezed!
1. v.digit -n dig
2. setup datatable columns connection (1 integer column titled wys)
3. fiddled with display settings a bit
4. digitized 3 or 4 lines, a boundary, entered attributes for each
5. deleted most objects leaving just 1
6. added few lines more again
7. wanted to "Move vertex", but the v.digit freezed - I couldn't even
"Save and wxit" or close the window, had to kill -9 it
Can't reproduce it at will.
The CPU usage was normal all the time.
No panning or zooming was performed, so
http://intevation.de/rt/webrt?serial_num=2962
is not an issue here.
But, plenty of
D0/0: Name = cat
D0/0: Name = wys
D0/0: Name = _grass_internal_database_encoding
D0/0: Name = _grass_internal_database_encoding
Could not set Tcl system encoding to
were printed to terminal, so maybe
http://intevation.de/rt/webrt?serial_num=4110?
Maybe that was the reason for the freeze?
Maciek
------------------------------------------------------------------------
CIEP?E KRAJE - CIEP?E MORZA. Szukasz atrakcyjnego wypoczynku w przyst?pnej cenie,
zapoznaj si? z nasz? ofert?.
ZAPRASZAMY
www.skarpatravel.pl
|
|
Sat, Jun 24 2006
16:18:00
|
|
Mail sent by glynn@gclements.plus.com (as #3087)
|
|
Return-Path |
<glynn@gclements.plus.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn@gclements.plus.com>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<17565.18832.197743.795084@cerise.gclements.plus.com>
|
Date |
Sat, 24 Jun 2006 15:17:52 +0100
|
To |
Markus Neteler <neteler@itc.it>
|
Cc |
Maciek Sieczka via RT <grass-bugs@intevation.de>, grass-dev@grass.itc.it
|
Subject |
Re: [GRASS-dev] Re: [GRASS-user] [bug #3087] (grass) high cpu usage on mouse ops
|
In-Reply-To |
<20060623141915.GI28533@bartok.itc.it>
|
References |
<20060622185115.D97CE101EF6@lists.intevation.de> <20060623120855.72acb2be.hamish_nospam@yahoo.com> <449B8D9C.2050603@itc.it> <17563.44892.563763.839671@cerise.gclements.plus.com> <20060623141915.GI28533@bartok.itc.it>
|
X-Mailer |
VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
|
X-Virus-Scanned |
by amavisd-new at intevation.de
|
X-Spam-Status |
No, hits=-3.072 tagged_above=-999 required=4 tests=[AWL=1.662, BAYES_00=-5, FORGED_RCVD_HELO=0.266]
|
X-Spam-Level |
|
Markus Neteler wrote:
> > > >>This bug's URL:
> > > >>http://intevation.de/rt/webrt?serial_num=3087
> > > >>
> ...
> >
> > One portable method to sleep for a fraction of a second is to use
> > select() with all descriptor sets NULL, e.g.:
> >
> > struct timeval tv;
> >
> > tv.tv_sec = 0;
> > tv.tv_usec = 500000;
> >
> > retval = select(0, NULL, NULL, NULL, &tv);
>
> Surprising question:
> Do we want to turn this somehow into a G_nanosleep()?
Probably, although G_usleep() would be more useful. I doubt that we
will ever need sub-microsecond precision, and using nanoseconds means
that you can't specify any value longer than ~4.3 seconds as a 32-bit
integer (whereas using microseconds allows ~72 minutes).
Also, the calls to sleep() (which isn't available on Windows) should
be replaced by G_sleep() (which can be implemented on top of
G_usleep()). The following files use sleep():
display/d.colors/interact.c
general/g.mapsets/main_cmd.c
imagery/i.class/curses.c
imagery/i.class/signature.c
imagery/i.ortho.photo/menu/run.c
imagery/i.ortho.photo/photo.2image/curses.c
imagery/i.ortho.photo/photo.2target/curses.c
imagery/i.ortho.photo/photo.2target/digit.c
imagery/i.ortho.photo/photo.2target/mark.c
imagery/i.ortho.photo/photo.rectify/ask_files.c
imagery/i.ortho.photo/photo.rectify/env.c
imagery/i.points/curses.c
imagery/i.points/digit.c
imagery/i.rectify/env.c
imagery/i.vpoints/analyze.c
imagery/i.vpoints/curses.c
imagery/i.vpoints/digit.c
imagery/i.vpoints/main.c
lib/gis/sleep.c
lib/raster/parse_mon.c
lib/vask/V_error.c
raster/r.le/r.le.setup/ask_group.c
raster/r.le/r.le.setup/setup.c
raster/r.le/r.le.trace/main.c
vector/v.transform/ask_trans.c
BTW, nothing appears to use the *_ltp() functions in lib/gis/sleep.c.
--
Glynn Clements <glynn@gclements.plus.com>
|
|
Thu, Aug 3 2006
02:16:04
|
|
Mail sent by guest
|
|
I can't confirm this behavior on Ubuntu 6.06 with grass cvs 2006-07-31. CPU
usage flucuates between 0-10% when the point, line, and boundary digitizing
tools are activated and awaiting response from the user. So I think it's safe
to assume this is obsolete v.digit behavior.
~ Eric.
<epatton at nrcan dot gc dot ca>
|
|
Thu, Aug 3 2006
15:25:33
|
|
Request 3087 merged into 2746 by msieczka (as #3087)
|
|
Thu, Aug 3 2006
15:28:32
|
|
Status changed to resolved by msieczka
|
|
Thu, Aug 3 2006
15:28:32
|
|
Mail sent by msieczka
|
|
CPU usage on mouse ops is OK for me too. I was only waiting for a reply from
the reporter before closing this report, which didn't happen. So closing now.
Maciek
|
|