No subject

Net.Noise owner news at max.cecer.army.mil
Mon Feb 8 15:59:52 EST 1993


Newsgroups: info.grass.programmer
Path: zorro.cecer.army.mil!shapiro
From: shapiro at zorro.cecer.army.mil (Michael Shapiro)
Subject: Re: help
Message-ID: <C25EBq.Btt at news.cecer.army.mil>
Sender: news at news.cecer.army.mil (Net.Noise owner)
Organization: US Army Corps of Engineers Construction Engineering Research Labs
References: <9302071728.AA09859 at tembo.rutgers.edu>
Date: Mon, 8 Feb 1993 20:59:50 GMT
Lines: 29

In <9302071728.AA09859 at tembo.rutgers.edu> kangang at tembo.rutgers.edu (Gregory K.G. Xu) writes:

>Hi,
>	I have one problem with grass library function "R_get_location_with_point()". When I interrupt the program, which is waiting the mouse button by this 
>function, by Ctr-C or C function "exit()", it still wait the mouse button to 
>click. Otherwise no command(such as "d.frame -e") can be executed. Is there 
>anyone knowing why? Thank you!

>greg

Yes, this is true. The reason has to do with the way GRASS communicates with
the driver. It uses fifos (named pipes). For example d.where issues a
R_get_location_with_pointer() call and waits for the driver to respond.
The driver then waits for the user to click the mouse. If d.where dies,
the driver can't know this since it is waiting for the user. The data
flow on the fifos is not event driven (ie it doesn't use interrupts to
know when to look for data on the fifo). So the driver waits for the user
to click the mouse. But, of course, the user doesn't know this since
he/she killed d.where. When d.frame starts it queues up its request,
but the driver doesn't see this until the use click the mouse.

The fifo communication process eventually should time out (for d.frame)
and issue a message that says something like "no response from graphics
driver - click the mouse".
-- 


Michael Shapiro U.S. Army CERL
Environmental Division       



More information about the grass-dev mailing list