[GRASS-dev] Re: [GRASS GIS] #1184: "d.vect display=attr" imply grass open process but doesn't close them.

[GRASS GIS]

#1184: "d.vect display=attr" imply grass open process but doesn't close them.
------------------------------+---------------------------------------------
 Reporter:  met               |       Owner:  grass-dev@…              
     Type:  defect            |      Status:  new                      
 Priority:  critical          |   Milestone:  6.4.2                    
Component:  wxGUI             |     Version:  6.4.0                    
 Keywords:  wingrass, d.vect  |    Platform:  MSWindows XP             
      Cpu:  Unspecified       |  
------------------------------+---------------------------------------------

Comment(by mmetz):

 Replying to [comment:5 hamish]:
 > `dbf.exe`s still piling up in the process manager with latest 6.4.svn
 native wingrass nightly build. what's more if you select disp=attr
 attrcol=label the wxGUI locks up with an endless hourglass. the "this
 program is not responding" dialog helps you kill it and get back to the
 working msys prompt where you can restart it with g.gui. (but the
 `dbf.exe`s remain running)

 Non-display commands that do very similar things to `d.vect
 disp=shape,attr attrcol=col` run just fine through the wxGUI, finish
 successfully and do not leave stray `dbf.exe` processes behind.

 Display commands are run through gcmd.!RunCommand() which in turn calls
 grass.script.core.start_command() which in turn calls
 grass.script.core.Popen(). Non-display commands invoked through wxGUI are
 run through gcmd.Popen().

 The endless hourglass goes away if ps.communicate() is replaced with
 ps.wait() in gcmd.!RunCommand(), d.vect finishes successfully and labels
 are drawn. But it leaves a stray `dbf.exe` process behind.

 Interestingly, the grass.script.core.*_command() functions and thus
 grass.script.core.Popen() are successfully used very often by the wxGUI,
 e.g. every time a column option field is populated. That does not leave
 stray `dbf.exe` processes behind.

 It seems that gcmd.!RunCommand() is doing something that prevents
 `dbf.exe` from finishing, or prevents G_wait() from properly waiting for
 `dbf.exe` to finish, whereas gcmd.Popen() runs fine.

 This affects all branches.

 Markus M

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1184#comment:7>
GRASS GIS <http://grass.osgeo.org>