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

Previous Next

Full log

View this message in rfc822 format

From: Andrew Cohen <acohen <at> ust.hk>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 63620 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, michael.albinus <at> gmx.de, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#63620: 30.0.50; [Feature Request] run hooks on sleep/wake
Date: Fri, 7 Feb 2025 19:43:32 +0800 (GMT+08:00)

Feb 7, 2025 19:16:03 Ship Mints <shipmints <at> gmail.com>:

> On Fri, Feb 7, 2025 at 2:14 AM Andrew Cohen <acohen <at> ust.hk> wrote:
>>
>> I spent some time looking over the documentation and the general
>> recommendations for dealing with sleep notifications. The 
>> recommendation
>> (from systemd/logind) is that any application that needs to do 
>> something
>> prior to sleep should monitor for sleep notifications and install the
>> block preventing sleep at the time that monitoring starts. When a
>> notification of sleep is received the application should complete its
>> work and then remove the block. After waking up, the block should be
>> restored.
>
> The semantics on macOS are still a bit murky to me and the API is 
> woefully under documented. The steps on macOS, I think, will be what we 
> discussed earlier where the block is put in place during sleep-request 
> handling. I will see if it is possible to follow the same method as 
> gnome but it may have to be through experimentation (that'll be super 
> fun).
>
> The other thing I was able to find in documentation from last decade is 
> that there are two kinds of sleep, kind of as you'd expect:
>
> - Forced sleep where the user explicitly does something like closing a 
> laptop lid or pressing a sleep button. This kind of sleep can be 
> briefly delayed but not blocked by an application.
>
> - Inactive sleep where the system sleeps on user idleness. This kind of 
> sleep can be both delayed and blocked.
>
> Let's keep the potential semantics and processing differences in mind 
> when designing how to make this work across platforms. It may be 
> possible to have one system implementation emulate another but that 
> could be cumbersome vs. a more accommodative structure.


Sure. Having thought a bit more I am convinced that starting the block 
before the sleep notification is the right thing, and am hopeful that 
macos can accommodate it. I think that with logind putting the block on 
AFTER the notification is actually not allowed (at least it seems that 
way in my testing.

But I suspect we can accommodate both approaches if necessary.

Can I get any feedback about the file descriptor closure issue? From what 
I can tell without exposing it in lisp the way I did I won't be able to 
use blocking anyway.

Previous Next

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