#61 Nice return from the main loop instead of exit

[Bob Usuario]

We have one window to monitor the status of the simulation and another to visualize the simulation using glut. The simulation should run for days, but the visualization is not always neccesary, besides is CPU consuming.

The current implementation uses exit() on the glutMainLoop, glutMailLoopEvent and fgError. That causes the application to finalize; killing all other threads, days of simulation data could be lost because there is no chance of flush and someone could get a heart attack.

Is it possible to have nice return from the main loop instead of killing the application?

[John F. Fay]

The "fgError" function is called from deep within the library so we really can't give it a nice return instead of calling "exit." If the library has called "fgError" something has gone badly wrong anyway, though, and you don't want your application to keep running because you cannot trust the results.

I can't speak for multi-threaded programs, but if you never call "glutMainLoopEvent" then "freeglut" won't take any CPU cycles.

[Chris Marshall]

One possibility to support a "soft fail" is via a user installed error
handler (as in feature request #2116152 in this tracker).

I agree that on fgError() being called, the GLUT library is
suspect from then on. In the case of a perl binding to
FreeGLUT using the library, calling exit(1) *kills* the
perl interpreter meaning that there is no way to exit
cleanly from the perl application since if exit() is
called, user exception handlers are not processed.
I'm not sure how FreeGLUT errors would make the
perl interpreter suspect and not usable to clean
up the application post-fgError.

--Chris

[Diederick C. Niehorster]

Implemented fgError and fgWarning callbacks (quite a while ago), see feature request 2116152.

Nice exits from mainloop are supported e.g. by setting glutSetOption(GLUT_ACTION_ON_WINDOW_CLOSE,GLUT_ACTION_CONTINUE_EXECUTION);