Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: atexit(), dlclose() and more atexit()

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 '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

Home | Main Index | Thread Index | Old Index