[Development] Ref-counted quit
thiago.macieira at intel.com
Mon Jan 2 15:44:19 CET 2012
On Monday, 2 de January de 2012 14.39.40, Stephen Kelly wrote:
> On Monday, January 02, 2012 10:51:31 Thiago Macieira wrote:
> > > Does the manager keep track of its delegates?
> > Good question. I guess it would depend on the windowing system, if we have
> > a notification of remote windows being closed. I'd like it to be
> > automatic, of course. Also, programmatically closing this object should
> > send the appropriate close events to the remote window over the windowing
> > system, if supported.
> Not just remote windows being closed. In this usecase there is not one
> window per running job. It might be just an entry in a QListView. So
> sending a close event to the delegate through the windowing system might
> not make sense.
Agreed, it needs to support a "windowless" mode, when the out-of-process UI
element is not a full window, just an entry somewhere else.
> > > How is your proposal open to abuse (of the API - I don't mean from a
> > > security POV)?
> > Being clear what it's about should be deterrent enough.
> Being clear about what ref/deref is about should be deterrent enough.
Not exactly. An API like "ref" and "deref" in QCoreApplication is easily
abused. Everyone uses QCoreApplication, so they're likely to see the
documentation for it. So they're likely to use and abuse the API, especially
if they have such trivial, overloaded and non-informative names like "ref" and
I'm asking for an outside class at a minimum. Some discussion on IRC:
11:30 <+ossi> well, at least the proxy objects allow some kind of
11:31 <+ossi> "wtf is this not quitting? let's consult the list of registered
11:31 < w00t> that's true
11:31 < w00t> ref/deref wouldn't allow that as easily
> > If possible, I'd like the construction to involve having a window ID of
> > some sort that ensures that it isn't easily abused.
> What if I use my own winId?
> delegate = new Delegate(myWidget->winId(), this);
> Would that be abusing the API?
No doubt. Qt cannot prevent people from dereferencing null pointers either.
There's always a way to abuse an API. I'm asking for a minimum of work so that
it isn't so easy to abuse.
> > > Does your proposal actually solve any of the problems you say must be
> > > solved by the API?
> > Yes, it's clear what it is about: managing this application's state about
> > out- of-process windows.
> Also solvable by simply using different method names for ref/deref, or
> creating a simple class to wrap those methods. Your winId proposal has no
> advantage over that.
It does if the purpose is to manage windows, which is the only use-case I am
considering. If we allow for more, then a class without winids may be the
> class QApplicationAutoQuitter
> QApplicationAutoQuitter(QObject *parent = 0)
> But of course that's still also open to all kinds of bugs because someone
> could new the class and not delete it. I'm not certain it's any better.
It's easier to track down. A full-blown object could have a registry
somewhere, so tools like Gamma Ray can inspect which objects are still alive.
The backtrace of the constructor can be saved, like QSharedPointer does, so we
can easily pin-point which lock didn't get freed. Also, tools like Valgrind's
memcheck would detect leaks of this object if all you did was new.
It's not possible to do that with ref/deref. At a minimum you need to get an
ID when you ask for the lock and you need to release the lock with that ID. So
the minimum API acceptable is like that of QObject::startTimer / killTimer.
> > You may also want to investigate how this would integrate with a concept
> > like Android's "wakelock", which is a way for applications to tell the
> > kernel that an on-going job is happening and the CPU should not completely
> > suspend. That is, it may enter low-power states, but it cannot suspend
> > operations completely. (TBH, it feels like a hack for not fixing
> > application's that fail to remove their wake-up timers, but it's besides
> > the point)
> That sounds not in scope of what I'm proposing.
It does to me. We're talking about preventing an application from quitting
while it's executing a task. That sounds very similar to preventing the CPU
from suspending all execution when the application is executing a task.
I am not saying it should be the same class, but I think that this other
functionality's needs should be investigated. We may want to add wakelocks in
the future, so having a similar API for quit-lock and wake-locks would be
It also sounds very similar to quit-locks in session management -- have you
ever noticed how KDE fails to quit when Skype is running? When you quit KDE,
only Skype closes, then the SM says the quitting was interrupted.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/development/attachments/20120102/e16c8f3c/attachment.bin
More information about the Development