Subject: Re: bug#63620: 30.0.50; [Feature Request] run hooks on sleep/wake

From: Ship Mints <[email-masked]>
Date: Fri, 7 Feb 2025 07:51:19 -0500

On Fri, Feb 7, 2025 at 7:18 AM Eli Zaretskii <[email-masked]> wrote:

> > Date: Fri, 7 Feb 2025 19:43:32 +0800 (GMT+08:00)
> > From: Andrew Cohen <[email-masked]>
> > Cc: [email-masked], Stefan Monnier <[email-masked]>,
> >       Eli Zaretskii <[email-masked]>, [email-masked]
> >
> > 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.