Exception RuntimeError: RuntimeError('main thread is not in main loop',)

In the main program I call modules (five times). In each module I use joblib.Parallel in the same way. If I call only one of these modules from the main program, everything is doing great. If in the main program I choose the option to execute the five modules one by one, in the third of them I get the following error:

Exception RuntimeError: RuntimeError('main thread is not in main loop',) in <bound method PhotoImage.__del__ of <Tkinter.PhotoImage instance at 0x7f72ac673c68>> ignored
Tcl_AsyncDelete: async handler deleted by the wrong thread
Aborted

When only that third subprogram (module) is called, everything is executed without error. joblib-0.13.0, Debian

[Naereen]

My diagnosis seems correct, I won’t need more, I just changed back and no longer open any matplotlib plots before being completely done with the Parallel-code. It’s not worth my time trying to find a better solution. Thanks again for your reply!

[Naereen]

Hi @tomMoral, thanks for the quick reply 👍!

I understood the bug (I think): if a first figure is created (but not manually deleted with del fig) before I run my Parallel(...)(delayed(...)) code, then the garbage collector can decide (pseudo)randomly to delete the figure anytime, in one of the thread. This makes the code break, because tkinter doesn’t support multi-threaded code, as soon as this garbage collector delete does not happen in the main thread (which explain why the bug happened faster on my 4-core & 4-thread machine than on another 12-core & 12-thread machine).

I’ll try again to verify if my diagnosis is correct. if it is, then I don’t think we can do anything: tkinter is known to not work in multi-threaded environment, and joblib can’t magically decide to preventively close all matplotlib figures before going into Parallel-powered code! If my diagnosis is wrong, I’ll provide a minimal working example that can be launch in a virtualenv, so you can test the bug. Thanks!