From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Pascal d'Hermilly <pascal@tipisoft.dk>, linux-acpi@vger.kernel.org
Subject: Re: Suspend-to-ram/disk signal
Date: Wed, 28 Nov 2007 02:10:14 -0200 [thread overview]
Message-ID: <20071128041014.GA18131@khazad-dum.debian.net> (raw)
In-Reply-To: <200711270036.21884.rjw@sisk.pl>
On Tue, 27 Nov 2007, Rafael J. Wysocki wrote:
> On Monday, 26 of November 2007, Pascal d'Hermilly wrote:
> > When the computer suspends and comes back does it send a signal to the
> > running applications?
>
> No, it doesn't. Applications aren't supposed to notice the suspend.
Except, of course, when they need to notice the suspend. The clocks
changed, the hardware configuration may have changed, and something
certainly did happen, so "Applications aren't supposed to notice the
suspend" is a naïve proposition at best. They need to *deal well* with it,
instead.
ntp needs to reset everything, for example. A LOT of software really
dislikes large steps in the clocks (monotonic or gettimeofday()), and
misbehave. Not notifying them they need to resync themselves is part of the
breakage. Multimedia applications and screen savers are often plagued by
this sort of problem.
A deskptop suite trying to emulate the ThinkVantage suite in a ThinkPad
might want to check that the user woke up the laptop just to eject the bay,
and ask him if he wants the box to go back to sleep, and maybe even offer to
do so automatically from now on.
The possibilities are endless...
> Your distribution surely uses some scripts that activate the kernel's suspend
> code. You can modify these scripts to notify your application.
Which is, of course, one way to work around the issue (and probably the best
one, since trying to act upon a wakeup out-of-sync with whatever said script
might be doing is likely not going to be very wise).
But it would still be nice if we kicked userspace in the arse to let it know
it was sleeping for a while and needs to resync, when we wake up each
userspace task. The kernel makes that information available to kthreads
for a damn good reason. Sounds like a job for a SIGCONT, but I don't know
how well would that work.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2007-11-28 4:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-26 22:39 Suspend-to-ram/disk signal Pascal d'Hermilly
2007-11-26 23:36 ` Rafael J. Wysocki
2007-11-28 4:10 ` Henrique de Moraes Holschuh [this message]
2007-11-29 0:28 ` Rafael J. Wysocki
2007-11-29 15:16 ` Henrique de Moraes Holschuh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071128041014.GA18131@khazad-dum.debian.net \
--to=hmh@hmh.eng.br \
--cc=linux-acpi@vger.kernel.org \
--cc=pascal@tipisoft.dk \
--cc=rjw@sisk.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox