[mythtv] QThread vs. pthreads

[Keith Layne]

> -----Original Message-----
> From: mythtv-dev-bounces at mythtv.org [mailto:mythtv-dev-bounces at mythtv.org]
> On Behalf Of Daniel Kristjansson
> Sent: Tuesday, January 02, 2007 6:25 AM
> To: Development of mythtv
> Subject: Re: [mythtv] QThread vs. pthreads
> 
> I think by platform-independent we generally mean it should
> either be in POSIX or implemented in Qt 3.1. A lot of UNIX
> procedures can be used in a POSIX compliant way, or in a
> non-POSIX compliant way. Newer Qt's support concepts such
> as 64 bit integers, but if you use this then you lose
> compatibility with some still popular distros.
> 
> We also do use some pthread attributes and priority settings
> that aren't supported by QThread. Some of the threads could
> be implemented as QThreads, but we might as well use the
> same thread API for all the threads we can. Plus pthreads
> are available on all operating systems MythTV could possibly
> run on. For MS Windows it's a tiny library which just
> encapsulates the same functionality in WIN32.
> 
> -- Daniel

Thanks for the info...I wasn't aware that pthreads existed on WIN32 outside
of cygwin (not that I checked...).  Are the distros that use older versions
of Qt mostly special-purpose?  I'm kind of a fan of of Qt, and I wasn't
planning on using Qt3 anymore if at all possible.  I know that porting to
QT4 is on the to-do list for myth...is it already being done?  Are there SVN
branches that I don't know about?  

I'm pretty satisfied with what mythtv does.  I just started digging because
there's a feature I would like to work on, and then I see thinks that could
be implemented differently that I think would make it easier to do what I
want to do...I don't even know what's necessarily being worked on right now.
I got a reply to a post that something was being worked on, but committing
it to SVN could happen any time in the future.  Right now I have a rare
combination of time and motivation, but I don't want to duplicate or
obsolete anyone else's work, and any patch too significant is sure to be
rejected.

More on topic...my understanding is that Qt uses pthreads as the basis of
the QThread class when possible.  You would think that they would have
developed a more full-featured thread class by now...(not to mention some
other things, like better audio support across platforms--can't they do
better without breaking the license?)  Anyway, at the risk of reinventing
the wheel, from a design and maintenance standpoint it makes sense to me to
make a myth thread class.  If myth will require pthreads, just let it
encapsulate that, and add some myth-specific stuff for debugging or
whatever.  With such a heavily threaded application there ought to be a
standard way to do it that still allows all the power of the underlying
library.  What I would like to see also is a kind of central registry for
all running threads or some other way to manage them in myth.  I've seen a
lot of threads created and then the tid just goes out of scope, which isn't
necessarily good.

Anyway, this all came about when I wanted a nicer way to configure my
remote, which is really just a small thing.  I thought it was weird that the
backend had to be relinked when I fiddled with the lirc code.  This is
another idea that may involve to much work for me get it approved:  why not
factor that stuff out of libmyth and replace it with a "plugin"
facility...obviously not the way that plugin is meant now for myth, but a
system that would allow plugins for input methods (lirc, etc.)  Also, it
would be nice to make a plugin interface for other things, like running
mplayer/xine/whatever.  Instead of the user figuring out what command line
they need to run for xine, a plugin that could help configure itself and be
used to play back a video could be simple and helpful to the end user.

I hope that didn't come off as a rant...I really like this piece of software
and want to contribute...thanks for all your work.

Keith