WinGRASS doesn't allow to close console window

[martinl]

Steps to reproduce:

1. Open GRASS with wxGUI
2. Close wxGUI
3. Enter exit

The terminal window hangs due to unfinished Python wxGUI-related process. So it's seems to be wxGUI bug...

[martinl]

Replying to martinl:

Steps to reproduce:

# Open GRASS with wxGUI # Close wxGUI # Enter exit

The terminal window hangs due to unfinished Python wxGUI-related process. So it's seems to be wxGUI bug...

[martinl]

See also #2291

[annakrat]

So, I found the revision since when the problem starts, it's r59204, there is something related to threading but I don't really know what's going on there.

It applies to Linux, too. wxGUI leaves a Python process behind.

[annakrat]

Replying to annakrat:

So, I found the revision since when the problem starts, it's r59204, there is something related to threading but I don't really know what's going on there.

It applies to Linux, too. wxGUI leaves a Python process behind.

The problem was actually there even before but it appeared only when g.gui.iclass was running because the threading class gThread was used only there.

[annakrat]

So it seems that r60429 solves the problem, it makes the thread a daemon thread. I am not sure if there can be any negative consequences of it.

[glynn]

Replying to annakrat:

So it seems that r60429 solves the problem, it makes the thread a daemon thread. I am not sure if there can be any negative consequences of it.

The Python interpreter terminates when there are no non-daemon threads alive. Any remaining daemon threads will be killed at that point. Note that sys.exit() simply raises a SystemExit exception; if not caught, the calling thread (and only the calling thread) will be terminated.

Whether there are negative consequences to making other threads daemon threads would depend upon what those threads were doing at the time. If they need to complete a pending operation or perform clean-up, they won't get the opportunity.

Threads which can't safely be killed at any time shouldn't be daemon threads. They should have some mechanism by which they can be instructed to terminate in an orderly manner. One option is to have the main thread instruct such threads to terminate when it is about to terminate (whether normally or upon an exception, including SystemExit). Another option is to have the additional threads periodically check whether the main thread is alive, and terminate if it isn't.

[annakrat]

Backported in r60489.

[hellik]

Replying to annakrat:

So it seems that r60429 solves the problem, it makes the thread a daemon thread. I am not sure if there can be any negative consequences of it.

tested here with

System Info                                                                     
GRASS Version: 7.1.svn                                                          
GRASS SVN Revision: 60466                                                       
Erstellungsdatum: 2014-05-25                                                    
Build Platform: i686-pc-mingw32                                                 
GDAL/OGR: 1.11.0                                                                
PROJ.4: 4.8.0                                                                   
GEOS: 3.4.2                                                                     
SQLite: 3.7.17                                                                  
Python: 2.7.4                                                                   
wxPython: 2.8.12.1                                                              
Platform: Windows-7-6.1.7601-SP1 (OSGeo4W)

confirmed. console windows closes now.

thanks.

[martinl]

Replying to annakrat:

Backported in r60489.

Confirmed, closing the ticket. Thanks.