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

Previous Next

Full log

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

From: Ship Mints <shipmints <at> gmail.com>
To: Andrew Cohen <acohen <at> ust.hk>
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: Re: bug#63620: 30.0.50; [Feature Request] run hooks on sleep/wake
Date: Fri, 7 Feb 2025 07:05:58 -0500

[Message part 1 (text/plain, inline)]

Do we need to consider not blocking sleep when Emacs is run in batch mode?

On Fri, Feb 7, 2025 at 6:43 AM Andrew Cohen <acohen <at> ust.hk> wrote:

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

[Message part 2 (text/html, inline)]

Previous Next

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