This topic needs a title

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

In <9302071728.AA09859@tembo.rutgers.edu> kangang@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