Suspend-to-ram/disk signal

Suspend-to-ram/disk signal

[Pascal d'Hermilly]

When the computer suspends and comes back does it send a signal to the 
running applications?

Specifically I would like to use it so a IM client will reconnect to the 
server instead of saying there is a timeout.

Hope someone can help me out with a tip.

//Pascal

Re: Suspend-to-ram/disk signal

[Rafael J. Wysocki]

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.

> Specifically I would like to use it so a IM client will reconnect to the 
> server instead of saying there is a timeout.
> 
> Hope someone can help me out with a tip.

Your distribution surely uses some scripts that activate the kernel's suspend
code.  You can modify these scripts to notify your application.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: Suspend-to-ram/disk signal

[Henrique de Moraes Holschuh]

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

Re: Suspend-to-ram/disk signal

[Rafael J. Wysocki]

On Wednesday, 28 of November 2007, Henrique de Moraes Holschuh wrote:
> 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...

OTOH, there are applications that need not be notified in any way, so I don't
think we should uncondtionally send signals to all of them, for example.

> > 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.

It wouldn't work very well, IMHO, unless the tasks in question are prepared to
get an "out of order" SIGCONT.

However, sending SIGSTOP to selected tasks before the suspend and then SIGCONT
after the resume might do the trick.

Greetings,
Rafael
-
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

Re: Suspend-to-ram/disk signal

[Henrique de Moraes Holschuh]

On Thu, 29 Nov 2007, Rafael J. Wysocki wrote:
> > 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...
> 
> OTOH, there are applications that need not be notified in any way, so I don't
> think we should uncondtionally send signals to all of them, for example.

IMO, "need not be notified" != "must not be notified".  *If* it doesn't
cause trouble for the vast majority of applications, notifying them all is
better.

> > 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.
> 
> It wouldn't work very well, IMHO, unless the tasks in question are prepared to
> get an "out of order" SIGCONT.

It is a actually a bug if anything can't take multiple SIGCONT's in a row,
AFAIK.  Most applications don't pay attention to SIGSTOP and SIGCONT at all
anyway, and let the default handlers take care of it (and those do the right
thing if they receive multiple signals).

> However, sending SIGSTOP to selected tasks before the suspend and then SIGCONT
> after the resume might do the trick.

Or to all userspace tasks that are not part of the "suspend process
interface" (for suspend2 UI) come to think of it, since we ARE going to
freeze them anyway.  I.e. "send SIGSTOP to all but some selected tasks..."
:-)

-- 
  "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