there are a few possible cases with varying amounts of problems:
opening a bunch of windows at once (like cl-glut-examples:run-examples does)
this mostly works, except in that case display-window returns immediately, and things that don't expect it might try to clean up as soon as it returns rather than waiting for a close event.
opening a new window from a glut callback
In the normal case, display-window calls main-loop automatically. This might sort of work, but running nested main-loop is probably a bad idea (and if it doesn't, the above problem of things trying to clean up too soon applies.)
opening new windows or running multiple things from separate threads
Lots of problems with this one.
freeglut probably isn't thread safe for creating/destroying windows (global list, no locking?)
Running multiple main-loop in separate threads is probably pretty bad, I think they will all try to run all windows?
Not sure if gl contexts etc are being set correctly in the right threads
possible cause of #81 when running mainloop sees new window too soon?
For the run-examples case, avoid that pattern in examples, and maybe add some notes to display-window.
For opening windows from callbacks, set a special to avoid running nested main loop, and add an example to test it?
Multiple threads case is harder, but possibly could help with #9. Would probably need to notice there is a running main loop, and then in that case send display-window commands to that instead of running them directly. Not sure if we can actually wake up the other main loop from the outside though? Might need to force an idle or timer callback, or switch to the freeglut polling API (glutMainLoopEvent)?
Possibly worth just refusing to even try to create windows on other threads while a main-loop is running on other threads to start with, so it at least fails predictably and informatively.
there are a few possible cases with varying amounts of problems:
cl-glut-examples:run-examplesdoes) this mostly works, except in that casedisplay-windowreturns immediately, and things that don't expect it might try to clean up as soon as it returns rather than waiting for acloseevent.display-windowcallsmain-loopautomatically. This might sort of work, but running nestedmain-loopis probably a bad idea (and if it doesn't, the above problem of things trying to clean up too soon applies.)Lots of problems with this one.
main-loopin separate threads is probably pretty bad, I think they will all try to run all windows?For the
run-examplescase, avoid that pattern in examples, and maybe add some notes todisplay-window.For opening windows from callbacks, set a special to avoid running nested main loop, and add an example to test it?
Multiple threads case is harder, but possibly could help with #9. Would probably need to notice there is a running main loop, and then in that case send
display-windowcommands to that instead of running them directly. Not sure if we can actually wake up the other main loop from the outside though? Might need to force an idle or timer callback, or switch to the freeglut polling API (glutMainLoopEvent)? Possibly worth just refusing to even try to create windows on other threads while amain-loopis running on other threads to start with, so it at least fails predictably and informatively.