On Thu, May 27, 2010 at 04:05:43PM +0100, Alan Cox wrote:
> > Now, if the user is playing this game, you want it to be scheduled. If
> > the user has put down their phone and the screen lock has kicked in, you
> > don't want it to be scheduled. So we could imagine some sort of cgroup
> > that contains untrusted tasks - when the session is active we set a flag
>
> I would hope not, because I'd rather prefer my app that used the screen
> to get the chance to save important data on what it was doing
> irrespective of the screen blank: "I have an elegant proof for this
> problem but my battery has gone flat"
Perhaps set after callbacks are made. But given that the approach
doesn't work anyway...
> What is the problem here - your device driver for the display can block
> tasks it doesn't want to use the display.
It's still racy. Going back to my example without any of the suspend
blocking code, but using a network socket rather than an input device:
int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
char foo;
struct sockaddr addr;
connect (input, &addr, sizeof(addr))
while (1) {
if (read(input, &foo, 1) > 0) {
(do something)
} else {
(draw bouncing cows and clouds and tractor beams briefly)
}
}
A network packet arrives while we're drawing. Before we finish drawing,
the policy timeout expires and the screen turns off. The app's drawing
is blocked and so never gets to the point of reading the socket. The
wakeup event has been lost.
--
Matthew Garrett | mjg59@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
