Re: non-racy examples, please (was Re: [PATCH 01/13] PM: Add wake lock?api.)

[Brian Swetland <swetland@google.com>]

["Woodruff, Richard" <r-woodruff2@ti.com>]
> > From: Pavel Machek [mailto:pavel@ucw.cz]
> >
> > Apparently, on android, if there's event ready on one of the input
> > devices, system will not go to sleep. That's quite an "interesting"
> > behaviour.
> >
> > Heh, they could rely on it and get rid of the wakelock. Just create
> > strange device that disallows system sleep when you select() on it,
> > and allows it when you read() from it :-).
> 
> Ok, thanks. When I looked quickly a couple months back I thought they 
> raised a user space side wake locks on input consumers.  These 
> translated back to the kernel lock and keep the system up.
> 
> Gist was something like you don't want to sleep until user activity 
> data was processed.  Any high latency sleep/suspend would be perceived 
> by user.

The intention is to make sure we hand-off "awakeness" from kernel to
userspace when the system is waking up to process an event.  Which is
why the event dispatcher in the framework select()s, grabs a wakelock if
readable (overlapping with the wakelock held when data is in the input
queue in the kernel), read()s the events (causing the kernel side to
drop its lock when the queue is empty) and dispatches them while holding 
the wakelock until things are sorted out.

Generally, arbitrary processes cannot open input devices in Android, so
this being a mechanism for abuse of keeping the system awake has not
been an issue thus far. 

Brian