[Kwintv] Re: OpenGL view mode and a new threading solution

[Koos Vriezen]

You wrote:
> On Sat, Jun 05, 2004 at 05:02:29PM +0200, Koos Vriezen wrote:
> > On Sat, Jun 05, 2004 at 01:04:27PM +0200, Dirk Ziegelmeier wrote:
> >  
> > > Another solution for the threading problems in kdetv may be a "XInitThreads()" 
> > > call in main.cpp. It works fine, only OpenGL freezes at widget creation. 
> > > Also, I found many places in the net where problems with this call are 
> > > described; even Qt does not call it by default. Does anyone have experience 
> > > with it?
> > 
> > I use it in kxineplayer (kdeextragear-2/kmplayer/src/xineplayer.cpp). According
> > to XInitThreads man page, it only works if all threads use the X(Un)LockDisplay
> > and not some other mutex for accessing the display. (which also means that
> > the grabber thread and Qt still excluding each other accessing the display)
> > What are exactly the "threading problems" btw. 
> The ones you fixed. I don't like the usage of the Qt lib mutex, because all 
> QDialog::exec() calls block video display due to recursive acquisition of the 
> Qt lib mutex (there are still a few remaining). And the shutdown of the V4L 
> plugin is quite a hack. When I use XInitThreads(), it looks like I do not 
> need XLockDisplay(), the app seems to work just fine (as long as I don't 
> create Qt events from the other thread). Only OpenGL has problems.

Don't know, sounds again replacing one hack with another (and also potential
dangerous, these X(Unl|L)ockDisplay are not there for nothing). Note also that
Qt higher level event loops are causing developers headaches not only here...
 
About the shutdown, IIRC there wasn't a shutdown procedure for plugins. Have
you tought about changing the plugins API for such a procedure. Alternative,
there could be a central QThread registration that could be waited for on
shutdown. I disagree the shutdown hack would justify the XInitThreads change ...

Koos