[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: New branch for replacing virtuals by Signals&Slots
From:       Martin =?utf-8?q?Gr=C3=A4=C3=9Flin?= <mgraesslin () kde ! org>
Date:       2011-03-02 21:44:47
Message-ID: 201103022244.56227.mgraesslin () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 02 March 2011 22:26:27 Sebastian Kügler wrote:
> On Sunday, February 27, 2011 15:28:37 Martin Gräßlin wrote:
> > With one thread it should always be direct methods call. If we have
> > threads  there I would say something is seriously broken. I cannot
> > imagine how we could pass a thread boundary there.
> 
> As far as I'm informed, the signal/slot mechanism has no guarantees to be
> direct calls, as Thomas said. Even if it "should be in most cases", that's
> probably not good enough to ensure code quality. If you want to ensure that
> a slot is immediately called (and not "somewhen soon"), you can use
> Qt::DirectConnection as additional argument to your connect().
> 
> See http://doc.qt.nokia.com/4.7/qt.html#ConnectionType-enum
<quote>(default) If the signal is emitted from a different thread than the 
receiving object, the signal is queued, behaving as Qt::QueuedConnection. 
Otherwise, the slot is invoked directly, behaving as 
Qt::DirectConnection.</quote>
For single-threading we are save. KWin core does not use threads and there are 
definately more places where everything starts to break if we would use 
threads.

Martin

["signature.asc" (application/pgp-signature)]

_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin


[prev in list] [next in list] [prev in thread] [next in thread]