GNU bug report logs - #63620
30.0.50; [Feature Request] run hooks on sleep/wake

Previous Next

Full log

Message #226 received at 63620 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: acohen <at> ust.hk, 63620 <at> debbugs.gnu.org, michael.albinus <at> gmx.de,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#63620: 30.0.50; [Feature Request] run hooks on sleep/wake
Date: Fri, 07 Feb 2025 15:05:23 +0200

> From: Ship Mints <shipmints <at> gmail.com>
> Date: Fri, 7 Feb 2025 07:51:19 -0500
> Cc: Andrew Cohen <acohen <at> ust.hk>, 63620 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, 
> 	michael.albinus <at> gmx.de
> 
>  > Having thought a bit more I am convinced that starting the block 
>  > before the sleep notification is the right thing
> 
>  This sounds strange to me.  Are you absolutely sure?  Did you try this
>  on some system?  Why would an application need to proactively block
>  sleep mode before the system announces its intention to sleep?  Won't
>  doing that prevent sleep, including one due to system idleness,
>  altogether?
> 
> On macOS, we can (via at least 4 different APIs with varying abilities--it seems like a historical mess):
> 
> - Block or unblock idle sleep. When blocked, it seems we will not get an idle sleep request from the OS since
> it's blocked. User-initiated sleeps cannot be blocked.
> 
> - Receive a request to accept or veto idle sleep. macOS waits for 30 seconds for a reply and will sleep if
> none received.
> 
> - Receive a notification that some other application has vetoed an idle sleep request.
> 
> - Receive a notification that the system is actually going to sleep. If acknowledged the system will sleep
> immediately, assuming every other application has also acknowledged. If not acknowledged, the system will
> sleep within 30 seconds.
> 
> I will have to put together an independent test jig for this and see what is what and discover the interactions
> between blocked sleep and sleep notifications. Apple's documentation is silent on this. I will also have to
> figure out which of the APIs or combinations of APIs are good ones, and not deprecated. I have not seen
> deprecations in Apple's documentation--yet.

I was talking about our reaction to the system's notification that it
is about to go to sleep.  The ability to block sleep regardless is a
separate feature, which doesn't need any mechanism of injecting an
event into the Emacs input queue.

For our reaction to the system's notification of an imminent sleep
mode, I'm surprised that we'd need to block sleep up front.  It should
not be needed.  Like macOS and MS-Windows, I believe GNU/Linux
provides the application with an ability to delay sleep, so that the
application could do what it needs in preparation for the sleep.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.