[mythtv] QThread vs. pthreads

Daniel Kristjansson danielk at cuymedia.net
Tue Jan 2 22:07:03 UTC 2007


On Tue, 2007-01-02 at 13:34 -0700, Keith Layne wrote:
> Thanks for the info...I wasn't aware that pthreads existed on WIN32 outside
> of cygwin (not that I checked...).
Yup, there has been a third party library since the Win 95 days.
Plus Microsoft shipped a GPL package for Win2000, and they have
a full POSIX package you can buy for XP. The third party pthread
lib is still free.

> Are the distros that use older versions of Qt mostly special-purpose?
I don't think so, not everybody upgrades to the latest release
from their favorite vendor as soon as it comes out..

> 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 don't believe this is being looked at yet. Issac wants to drop
support for Qt 3.x when we move to Qt 4.x, this means we need to
wait until all the major distros have been shipping 4.x for a
year or so before doing the switch. Doing a switch like this
means we don't need to write wrappers and the port will not only
be much cleaner but we'll be able to use 4.x features without
re-implementing the functionality on top of a Qt 3.x.

> I'm pretty satisfied with what mythtv does.  I just started digging because
> 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.
That is a great thing to have :)

> 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...
Maybe this is in Qt 4.x? I'm not to familiar with Qt 3.1, since
I use those help pages to avoid introducing code that doesn't
compile for other MythTV users..

> (not to mention some
> other things, like better audio support across platforms--can't they do
> better without breaking the license?)
They wouldn't be breaking any licenses by wring a good
audio wrapper, the problem is more that their paying
customers don't need sophisticated audio output..

> 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. 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.
Ah, I see. Not a bad idea, but I think you should tackle some
smaller projects first, either adding features or fixing bugs.
Infrastructure patches tend to require the committer to read a
lot of code and do a lot of testing, so you it is best to
display your programming chops to some of the committers with
easier to review patches, so that they know looking at something
more complicated won't be a waste of their time.

> Anyway, this all came about when I wanted a nicer way to configure my
> remote, which is really just a small thing.
A great first project. There is a definite need for such a
thing and it doesn't touch on a lot of existing code so it
should be relatively easy to review.

> 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.)
This makes some sense, but again reviewing this code would be
a PITA and would require someone to assume the responsibility
of maintaining it. So it is not a good first project.

> 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.
This would probably be simpler and would be a good project to
tackle after something like the remote control configuration.

> 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.
It didn't. It can be difficult to find a place to start
with when looking at something as big as MythTV.

There is some developer documentation in these places:
  http://svn.mythtv.org/trac/wiki
  http://www.cuymedia.net/
  http://svn.mythtv.org/trac/wiki/TicketHowTo
  http://svn.mythtv.org/trac/wiki/FutureDevelopment

There is also a not so well organized feature wishlist
which has a lot of ideas people have contributed:
  http://www.mythtv.org/wiki/index.php/Feature_Wishlist

And the report of all outstanding bugs is here:
  http://svn.mythtv.org/trac/report/1

-- Daniel



More information about the mythtv-dev mailing list