On Mon 29 Jun 2020 at 10:39:45 +0200, Martin Husemann wrote: > On Mon, Jun 29, 2020 at 09:55:10AM +0200, Rhialto wrote: > > 6. said handler tells the new thread to clean up and finish. One of the last > > things the thread does, is to dlclose() libavformat. > > How can an atexit() handler (or a destructor) defer work to a thread > (w/o waiting for the thread to complete, but then the thread makes no > sense)? I'm boiling down things to the essence here. The "new thread" isn't just there to do cleanup. It has been running the CPU emulation of VICE for potentially a long time. When the GTK3 GUI (which runs on the main thread) lets the user choose the Quit menu entry, it starts shutting things down. Part of the shutdown happens in the atexit handler. When this CPU emulating thread gets notified that it should finish up, it also handles the dlclose(), which in turn deadlocks. It is basically an unfortunate distribution of cleanup tasks which causes a deadlock. But I wonder if there is any standards text that describes whether this particular scenario is supposed to work. > Martin -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG"
Attachment:
signature.asc
Description: PGP signature