Comment 25 for bug 967416

@jazzynico
Thanks, I think that would solve the crash, however some issues come to mind with that solution:
  1. It would introduce some global state, which would be tricky to reason about for anyone not familiar with the specifics. This is particularly complicated since it appears from the code everything is on the same thread.
  2. Other UI actions aside from saving are likely to be affected, any changes in each may silently trigger unsuspecting behavior due to this in the future (this may actually be causing some other bugs after saving as well?)

I didn't mention, but this main_loop can also cause multiple script saves to chain on the call stack: for example, if another save is performed instead of an exit, that save is actually running yet another file_save call (and thus running another g_main_loop_run). At this point there's 3 different entry points on the stack into file_save from the same thread, and although it may technically work, to me it seems brittle.

I think the culprit here is the extra main loop being run in the script, and I think the only clean solution would be to remove it completely. Upon closer investigation I think the only time it's actually stopped (in the context of saving) is if the appropriate file_listeners (stdout, stderr) have read data from the spawned script process. Although there is a Script::cancelProcessing, I think this is only called from an Extension Effect.

Would displaying a dialog window (replacing the _main_loop entirely) here instead work? This should block and the file_listeners and cancellation could then simply close it when completed. I'll see if I can play around with a solution, again my GTK experience is very basic so maybe there's a better approach.