PATCH: kwallet lockup (#65978/#71048)
Lubos Lunak
l.lunak at suse.cz
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 suse.cz , l.lunak at kde.org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
More information about the kde-core-devel
mailing list