[mythtv] Re: [mythtv-commits] mythtv commit: r7312 by danielk
danielk at cuymedia.net
Mon Sep 26 01:53:27 UTC 2005
On Sun, 2005-09-25 at 19:59 -0400, Isaac Richards wrote:
> On Sunday 25 September 2005 07:38 pm, Daniel Kristjansson wrote:
> > On Sun, 2005-09-25 at 18:48 -0400, Isaac Richards wrote:
> > It is ok to create a QObject outside of the Qt event thread,
> > but it can not be deleted while another class is sending it
> > a signal (for obvious reasons...)
> Pretty sure it's creation, too. Last I checked the Qt source, at least, it
>From the code it looks like in 3.3.4 at least it is thread-safe. What is
the oldest version we support now? 3.1? I can have a look at it...
> > To avoid needing to disconnect all slots before deletion,
> > QObject contains a "deleteLater()" method that queues it
> > up for proper deletion the next time the event loop runs.
> Signals are sent immediately, though. They aren't queued at all.
I wasn't clear. From reading the docs, I understood that
deleteLater() makes sure that the disconnects are completely
completed before the delete.
But I then I looked at the source. Unfortunately, all that
deleteLater() ensures is that QTimer signals won't happen
while the object is being deleted. It does not protect you
from other threads sending you an signal that finishes after
the class is deleted. (Or in a once in a lifetime event,
_arrives_ after the class is deleted; this can happen if a
context switch happens in qt_emit in the couple of instructions
in between getting the slot and calling the slot function.)
> > I'll make sure I use this on the recorders, and I'll check the
> > other QObject classes I know about...
> It's just a race condition, really - shouldn't _crash_ things, but still would
> be good to fix.
Well it shouldn't crash with how ~TVRec arranges deletions now.
The DVBSIParser is shut down before the recorder so there won't
be any signals from it to DVBChannel, nor from DVBChannel to
DVBRecorder. And since the recorder is shut down before TVRec
is deleted the RecorderPaused() signal won't be sent to TVRec
after it is deleted.
But someone might just connect up a QTimer to a slot in one of
the classes or re-arrange deletion order some day...
The safest thing to do is to stop all the threads before any deletion
in ~TVRec, then also use deleteLater() on all the QObject derived
classes so that any future QTimer events are safe. (I don't think we
currently use QTimers in any recording classes, so we are safe for now.)
More information about the mythtv-dev