[mythtv] re: mythtv commits

[avalanche at beyondmonkey.com]

----- Original Message ----- 
From: "David Engel" <dlengel at attbi.com>
To: "Development of mythtv" <mythtv-dev at mythtv.org>
Sent: Friday, November 21, 2003 1:04 AM
Subject: Re: [mythtv] Re: [mythtv-commits] mythtv commits


> On Thu, Nov 20, 2003 at 11:42:25PM +0100, avalanche at beyondmonkey.com wrote:
> > Sounds good, I attached a patch with some changes to the mutex stuff. I think 
> > it should hold up till you're done with the new socket class. ;)
> 
> I've done some googling and reading of man pages regarding Qt and
> think we might be making this harder than it has to be.  Of course, I
> could be totally off base too.
> 
> According to my reading, everthing GUI related, including event
> handling, must and does occur in only one thread.  Since we're not
> using multiple threads in the cases we've been discussing, we
> shouldn't need any mutexes at all.  All we should need to worry about
> is re-entrancy within a single thread, and that can be handled can be
> handled with the ignoreevents/allowKeys technique as long as we
> check/set/clear in the right places.

The last patch basically does just that, the locks are all non blocking
so they could be replaced with bools just as well.

It's still not 100% safe, if I understand it right all calls to stuff
that uses the event loop can cause reentrant events, that includes the
network stuff, and all emit etc. So all calls to the fill functions
would have to be protected since paint events can happen all the time. 
This would have to be done for all key events separately since you can't 
include the update() calls in the lock. 

The right and more transparent way would be to lock the event loop, but 
that can't be done since the socket stuff uses it.

I think that it's not that critical or people would have had problems
with it by now. The more critical customevents that happen when the 
edit recordings dialog etc. are displayed should be safe.

av