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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
