You've lost me.  If the power manager is sitting inside a select/poll, 
how can it miss the event (given that the event will make data 
available to be read on one of the descriptors being polled)?

Or put it another way: With wakelocks, if the app doesn't use a suspend
blocker then once it reads the event data and the timed wakelock is
deactivated, there is nothing to prevent the system from immediately
going into opportunistic suspend.  My scheme can fail in the same way.  

You should stress this point more strongly when conversing with others.  
I doubt it will be enough to change anybody's mind, but it can't hurt.  
Indeed, if you propose suspend blockers as a way to fix a lost-wakeup 
bug in existing distributions, rather than as something needed to 
support Android, people might view it more favorably.


There's one question that I don't remember ever seeing answered.  To
which kernel drivers do you intend to add suspend blockers?

Alan Stern

--

[ message continues ]

No, if an app reads from a file descriptor and block suspend when the
read call returns, then suspend is blocked while processing the data.
If the driver uses a wakelock with a timeout this will fail if the
thread does not get to the suspend block call before the timeout
expires, but unrelated events that don't prevent the app from running
will not cause any problems. In your scheme the user-space power
manager may miss events on this file descriptor since select/poll will
not see an event if the app read that event right before the power

All drivers that generate wakeup events need to either use suspend
blockers directly or call into something else that does. For instance,
with the patch to block suspend while input events are queued to
user-space, an input driver that fully handles its events in its
interrupt handler does not need any additional suspend blockers, but
if the driver needs a work function or a timer to run before it
reports the event it needs to block suspend until it has reported the
event.

-- 
Arve Hjønnevåg
--

[ message continues ]