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

[Koos Vriezen]

> On Sun, Jun 06, 2004 at 11:58:26PM +0200, Koos Vriezen wrote:
> > You wrote:
> > > On Sat, Jun 05, 2004 at 05:02:29PM +0200, Koos Vriezen wrote:
> > > > 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).
> I wouldn't consider making XLib thread-safe a hack... I'd call it a clean 
> solution (much cleaner than qApp->lock()).

No, don't get me wrong here. I read the XInitThreads man page so that you
need X(Unl|L)ockDisplay also when really accessing the display:
      The XLockDisplay function locks out all other threads from using the
      specified display.  Other threads attempting to use the display will
      block until the display is unlocked by this thread.  Nested calls to
      XLockDisplay work correctly; the display will not actually be unlocked
      until XUnlockDisplay has been called the same number of times as XLock-
      Display.  This function has no effect unless Xlib was successfully ini-
      tialized for threads using XInitThreads.
Ok, it's stated reversed.
My grep on the Qt sources didn't find a XLockDisplay call, so my fear is
that, allthough it might work for you, it could fail badly on other systems
(eg linuxthread/nptl and UP/SMP systems). But I could read it wrong of course,
but why is it there if it only works after calling XInitThreads...
  
> > About the shutdown, IIRC there wasn't a shutdown procedure for plugins. Have
> > you tought about changing the plugins API for such a procedure.
> There is, you can create and delete all plugins (this is what in fact is done, 
> e.g. when you change from a xv to a v4l device). The problem is the app 
> shutdown, last time I checked it, Qt deleted the app WITHOUT acquiring the Qt 
> lib mutex, and this is what made the app crash. I hacked around it by using 
> SIGNAL( aboutToQuit() ) to shut down the plugin.

Ah yes, sorry I forgot (/me remembered the ugly hack in my first patch that
temporary unlocked Qt when waiting for the thread to finish).
Indeed the alternative, central thread registration, remains then..

Koos

Btw, didn't try the opengl yet, will do so soon..