On Thu, May 27, 2010 at 07:02:04PM +0100, Alan Cox wrote:
> > This is still racy. Going back to this:
> >
> > 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 {
> > * SUSPEND OCCURS HERE *
>
> Fine but then the packet will arrive and we will wake back up process the
> packet and wake the task. See suspend is just like a deep sleep. If we
> went to sleep there and the packet arrival doesn't rewake the box the
> driver was buggy.
Yes, there's no problem so far. The question is how you guarantee that
the application has had the opportunity to handle the packet.
> > reaches the end of its timeslice. At this point the application has not
> > had an opportunity to indicate in any way whether or not the packet has
> > altered its constraints in any way. What stops us from immediately
> > suspending again?
>
> If my app level constraint before the packet is 'don't suspend' then my
> constraint on receipt is 'don't suspend' so I won't suspend. If my
> constraint is then lowered and I suspend I will suspend *after* the
> lowering.
If the app level constraint before the packet was "don't suspend", we
wouldn't have suspended. Here's a description of the desired behaviour
of the application as you requested:
The application is a network monitoring app that renders server state
via animated bouncing cows. The desired behaviour is that the
application will cease to be scheduled if the session becomes idle
(where idle is defined as the system having received no user input for
30 seconds) but that push notifications from the server still be
received in order to allow the application to present the user with
critical alerts.
Under Android:
User puts down phone. 30 seconds later the screen turns off and releases
the last user-level suspend block. The phone enters suspend and the
application is suspended. A network packet is received, causing the
network driver to take a suspend block. The application finishes the
frame it was drawing, takes its own suspend block and reads the network
packet. In doing so the network driver releases its suspend block, but
since userspace is holding one the phone stays awake. The application
then handles the event as necessary, releases its suspend block and the
phone goes to sleep again.
I don't see how this behaviour can be emulated in your model.
--
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
