41 lines
1.8 KiB
Plaintext
41 lines
1.8 KiB
Plaintext
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
|
|
|