[Mythtv-soc] Config-revamp update Jun 30,2006

[Daniel Kristjansson]

On Fri, 2006-06-30 at 21:38 -0400, Justin M. Hunt wrote:
> Hi everyone,
> This week I've continued getting the advanced & expert modes working,
> I am almost ready to commit the advanced mode and framework for expert
> mode.  Right now I'm battleing QT's signals and slots, when I change
> anything something else breaks, so its very slow going.   I should have
> advanced mode commited tonight and expert by tuesday next week.  

Yikes, I should have told you about the Qt problems in settings.{h,cpp}

There are certain rules you need to observe when using QObject
which are not observed by many classes in settings.{h,cpp}

* Multiple inheritance can never include more than one class
  derived from QObject. When multiple inheritance is used,
  the one QObject derived class must be first.
* Virtual inheritance of QObject derived classes is also verboten.

Neither the compiler nor moc will stop you from doing this, but the
signals will be sent to the wrong places or you will experience random
core dumps as Qt writes to random parts of memory. So basically part
of the UI rewrite has to include fixing these problems (otherwise
you are in for a world of pain).

There are other rules, see:
  http://doc.trolltech.com/3.1/moc.html
But I think we are OK with respect to the other ones. There are rules
not in the moc gotchas page, such as not allowing the use of "delete"
directly on QObject derived classes outside the Qt event thread, and
requiring you to remove all incoming signals not originating in the
Qt event thread before calling deleteLater() or allowing Qt to call
deleteLater(), as it does for you when tearing down the UI.

===

To everyone, no Qt classes are thread-safe, except for QMutex and
friends. This includes QString and other Qt container classes like
QMap. To pass a QString or other Qt container classes between threads
you must use QDeepCopy or convert them to some non-qt data type as
an intermediary step in assignment.

Some methods on some classes, such as QRegExp, are reentrant.
This meaning that multiple threads can use the method, so long as it
is impossible for another thread to change the underlying class while
a reentrant method is running. Other methods in the same class may
not be reentrant, for example QRegExp has other methods that are
both non-threadsafe and non-reentrant. If one of these methods is
running, no other method of the class, including reentrant ones, can
be running in another thread.

Since MythTV is a highly threaded application, this is something
to keep in mind whenever you use Qt classes. Also when you look
at Qt the documentation, look at Qt 3.1 documentation. Some problems
with thread-safety and reentrancy have been fixed in later editions
of Qt, plus there may be additional methods in later versions which
you can't use.

-- Daniel