MBOX-Line: From arnt at gulbrandsen.priv.no  Fri Jun 30 10:32:20 2006
To: imap-protocol@u.washington.edu
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Date: Fri Jun  8 12:34:37 2018
Subject: [Imap-protocol] IMAP disconnection
In-Reply-To: <Pine.OSX.4.64.0606301002220.408@pangtzu.panda.com>
References: <etPan.44a548f0.6bad5e90.d87@utopia>
	<kfeFnb6PW1GA+CfAeAs4lA.md5@libertango.oryx.com>
	<Pine.OSX.4.64.0606301002220.408@pangtzu.panda.com>
Message-ID: <rc1ASwIZw+RKCNvBsIFShQ.md5@libertango.oryx.com>

Mark Crispin writes:
> On Fri, 30 Jun 2006, Arnt Gulbrandsen wrote:
>> (When a user closes the lid, the laptop has to sleep right there and 
>> then. Not 30 seconds later.)
>
> Not so!  I've seen sleep-on-lid close take quite a bit longer than 30 
> seconds on some laptops; each running running application must 
> respond to a system sleep event.  To further muddy the waters, a 
> running application has the right to cancel the sleep!

Yes, any laptop vendor can specify most of the timeouts in ACPI, up to 
65534 ms, and OSes can go beyond that limit in many ways. The OSes I 
looked at even give the application some freedom, e.g. asking "how long 
will it take you to save state?". Back when I looked at this, I didn't 
see find case where OS code seriously allowed applications to cancel 
the OS response to events like lid close - the choice was really 
between suspending the nice way or suffer a worse fate when the the 
nice processes are done.

> The only true "SHUT DOWN NOW!!" operation is to hold down the power 
> button long enough that a hard power-off happens.  But, I've seen 
> laptops that were recalcitrant even with that, and thus it became 
> necessary to pull the battery.

(IIRC, that's indicative that some ACPI variable is set to 65535 by the 
vendor, and the OS wedged.)

Arnt

