Details Ticket 2746


Comment | Reply | Take | Open


Serial Number 2746
Subject nowadays tight loop while waiting for mouse input
Area grass6
Queue grass
Requestors jidanni@jidanni.org,turek2@poczta.fm
Owner none
Status resolved
Last User Contact Thu Aug 3 15:28:32 2006 (2 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Thu Aug 3 15:28:32 2006 (2 yr ago)
Created Wed Dec 1 06:43:25 2004 (4 yr ago)

Transaction History Ticket 2746


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
Comment | Reply | Take | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request