PATCH: kwallet lockup (#65978/#71048)

Lubos Lunak l.lunak at
Tue Jan 13 09:55:13 GMT 2004

On Monday 12 of January 2004 18:17, Dirk Mueller wrote:
> On Monday 12 January 2004 18:08, Lubos Lunak wrote:
> >  I'm afraid GUI not updating is insignificant
> it is significant imho.
> >  when compared to crashes or
> > lockups.
> but those crashes or lockups only happen when a qtimer is in the game,
> right? we can't block then in local event loops can we?

 And posted events (#70430 is actually the same principle). And there could be 
even code reacting to some X11 events that could cause trouble, although I 
don't think this would be very likely. But I don't see how we could block 
posted events without modifying Qt :(.

> seems like khtml has to be converted to use the asynchronous api, something

 Not only khtml, but everything that can create a popup, otherwise the 
kwallet<->popup deadlock can occur.

> which I wanted to avoid since  while it might close this problem, it will
> open an extremely huge can of worms inside khtml. I'm really not very
> confident in changing something like this in this phase of the release
> cycle.

 I think making the kwallet call blocking and closing all popups before it is 
a sufficient solution for 3.2. Ok, not updating the GUI may be significant, 
but the world will not tumble down. All other solutions I see are either 
worse, or need to be post-3.2 (be it making TT create some proper 
qApp->eventLoop()->processEvent( OnlyUpdateGUI ) or whatever).

Lubos Lunak
KDE developer
SuSE CR, s.r.o.  e-mail: l.lunak at , l.lunak at
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic

More information about the kde-core-devel mailing list