[Development] Ref-counted quit

Thiago Macieira 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 
"deref".

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 
discoverability
11:31 <+ossi> "wtf is this not quitting? let's consult the list of registered 
holders"
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 
solution.

> class QApplicationAutoQuitter
> {
>   QApplicationAutoQuitter(QObject *parent = 0)
>   {
>     qAppPrivate->refBikeshed();
>   }
>   ~QApplicationAutoQuitter()
>   {
>     qAppPrivate->derefBikeshed();
>   }
> };
> 
> 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 
extremely beneficial.

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: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120102/e16c8f3c/attachment.sig>


More information about the Development mailing list