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

Arve Hjønnevåg
2009-02-08T22:40:29Z

On Sun, Feb 8, 2009 at 2:17 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> Ok, I think that this wakelock stuff is in "can't be used properly"
> area on Rusty's scale of nasty interfaces.
>
> So... do I understand this correctly that if I want to run "make zImage"
> on Android, I'll need to modify make, gcc, .... to keep system awake?

Or you could grab a wake lock before starting the job. e.g.
"runwithwakelock make".

What prevents the system from suspending while you run make in your
existing system?

> (How to do that? Give all the userland processes access to
> /sys/wakelocks ?)

That depends, do you want users to be able to keep the system on?

> BTW what does android do when battery goes critically low? I believe
> you want to suspend, ignoring wakelocks, at that point.

I don't know for sure, but I believe it does a full shutdown.

> And now, you have some X-like system.
>
> /* We were idle for too long */
> blank_screen();
>
> unlock_all_wakelocks(); /* We want machine to sleep */
>
> wait_for_key();
> /* (here) */
> lock_wakelocks("processing_key_wakelock");
>
> ...is that approximately correct? There's race there, right? If (here)
> processing takes too long, or whatever, kernel will sleep the machine
> before it even displays "do you want to unlock the screen" dialog,
> right?
>
> Can you solve that in a way that works, always?

There is no unlock_all_wakelocks call, you unlock the "main" wakelock
by writing to /sys/power/request_state. There is no race in your
example as long as your wait_for_key function just does a select or
poll call and does not read the key events. The wakelock on the event
queue prevents sleep. This is what my example in the wakelock doc
describes.

--
Arve Hjønnevåg