[Development] Ref-counted quit

[Stephen Kelly]

On Monday, January 02, 2012 12:44:19 Thiago Macieira wrote:
> 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
> 

<snip>

> > 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.

Yes, true. There are many ways it is better. If it inherited QObject that 
would be enough for GammaRay at least (I didn't quite remember to put that in 
my class definition above). 

I am completely ok with some class like QQuitLock with a simple implementation 
like above. It came up weeks ago on IRC I remember too, but also at that point 
you wanted gui locks.

> > > 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.

I'm afraid I'm not familiar with wakelocks on Android or anywhere else, and 
I'm not familiar with quit-locks in session management either. 

If wake locks are as simple as you describe though, it sounds like something 
similar would work just fine.

class QWakeLock : public QObject
{
  Q_OBJECT
public:
  QWakeLock(QObject *parent = 0)
  {
    // tell kernel we need to be kept alive
    // (cf tell QCoreApplication to stay alive)
  }
protected:
  virtual ~QWakeLock()
  {
    // tell kernel it is safe to suspend 
    // (cf tell QCoreApplication to quit if no other locks exist)
  }
};

Thanks,

-- 
Stephen Kelly <stephen.kelly at kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120102/0f6d89c2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120102/0f6d89c2/attachment.sig>