On Fri, Feb 7, 2025 at 7:18 AM Eli Zaretskii wrote: > > Date: Fri, 7 Feb 2025 19:43:32 +0800 (GMT+08:00) > > From: Andrew Cohen > > Cc: 63620@debbugs.gnu.org, Stefan Monnier , > > Eli Zaretskii , michael.albinus@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.