[GRASS-dev] issues with compiling and running GRASS on Mac

[Glynn Clements]

Martin Landa wrote:

> >> > I don't know about the easiest way, but the only robust solution is to
> >> > keep nagging the wxGUI developers until they move the high-risk
> >> > features (vdigit, nviz) out of the main wxGUI process.
> >>
> >> it's my plan, I started to elaborate with NvizThread in nviz_mapdisp.py...
> >
> > Er, how does that help?
> 
> For nviz/vdigit extension, there two main points I would like to fix:
> 
> * when extension crash (G_fatal_error is called) to avoid crashing whole GUI
> * redirect message printed by extension to stdout, strderr to Layer
> Manager "Command Area" (goutput.py)
> 
> NvizThread class maybe can help in this effort (?)

Using another thread won't help protect against errors which occur
within C code; for that, you need a completely separate process. 
Threads just allow for concurrent execution; they don't provide
isolation.

exit() (as used by G_fatal_error()) terminates the process, not just
the thread. Likewise for fatal signals (e.g. SIGSEGV).

OTOH, A separate thread will help protect against Python exceptions,
which only terminate the thread which raised the exception.

Essentially, vdigit and nviz need to be separate applications. They
can "import" as many wxGUI modules as they want, but any sharing of
data between them and the main wxGUI process will require explicit
communication between the processes.

I'm aware that this results in either reduced usablity or increased
complexity (or some compromise between the two), but it's the only way
to ensure that an error in vdigit/nviz (or rather, in the C code which
they call) only terminates that component rather than the entire GUI.

-- 
Glynn Clements <glynn at gclements.plus.com>