Monitor locking question

[Conn Copas]

Martin Ameskamp writes:

       "I have a couple of (UNIX) processes running (communication is
        handled, very nicely, by PVM). One (call it 'eval') sits on my 3d 
        soil model and waits for a pair of coordinates, among other things.
        On receipt, it evaluates the model (rule based) and sends profile
        information on to a second process that displays it in a special
        (non-GRASS) window.

        Another process ('where') sits on top of the GRASS monitor and 
        waits for a mouse click. If it gets one, it converts this to UTM 
        (well, actually its Gauss-Krueger, but don't tell Jerry Evenden :-)
        and sends it to eval.

        While where is running, I want to do other things, like computing
        sections through the model and displaying them as GRASS raster files.
        Then I wnat to see profile information for places that look interesting
        on those maps. The problem is that I can't display maps while 'where'
        is running.

        At the moment, I simply start up and stop 'where' whenever necessary,
        since it's a fairly small program, it comes immediately (eval is
        a 4MB monster, including debugging information, though)"


So that's what you are trying to do. I am afraid there is no easy solution to
that problem. My suggested changes to io.c will allow you to bypass the Grass
locking mechanism, which can be useful when different processes wish to write
to one monitor in a pseudo-instantaneous fashion. However, d.where is not such
a discrete process. It opens up a connection with the graphics driver, and that
connection endures until the user performs a right mouse down. In the meantime,
any other process which attempts to communicate with the monitor faces the
problem that the pipes it wishes to use are already in use, and is locked out
because of low-level signalling considerations. The simplest strategy is to
transform d.where into a pseudo-discrete process by employing the '-l' flag,
and have some executive script controlling the synchronisation between this
command and d.rast (but it sounds like you may have come to that conclusion
already!).
 
-- 
Conn V Copas
Information Technology Division
Defence Science and Technology Organisation
PO Box 1500
Salisbury            tel: +61 (0)8 25 95349
SA  5108             fax: +61 (0)8 25 96781
Australia       e-mail: cvc at itd.dsto.gov.au
-------------------------------------------