On Fri, Aug 15, 2014 at 6:14 AM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> On Thu, 14 Aug 2014, at 11:00, Jonas Sicking wrote:
>> I am however more worried about that only having a request() and a
>> release() function means that pages that contain multiple independent
>> subsystems will have to make sure that they don't stomp on each
>> other's locks. Simply counting request() calls vs. release() calls
>> helps, but doesn't fully solve the problem. It's very easy to
>> accidentally call release too many times, in response to some UI
>> action for example.
>> An alternative design would be something like
>> x = new WakeLock("display");
>> x.request();
>> x.release();
>> Extra calls of either request() or release() are ignored, but pages
>> can create any number of WakeLocks of the same type.
> It seems that we already discussed using an object and this solution was
> dismissed because of this model being error-prone.

Where was this discussed? Why was it considered more error prone? Was
it related to the patterns discussed at


> It's also not clear
> how this solution is superior than the current solution [1] with regards
> to multiple releases or requests. In [1], if you call .request() or
> .release() multiple time, the promise reacts appropriately.

The problem arises when you have several semi-independent pieces of
code within a single page. Given that request() and release() is
likely going to happen in response to very different UI events or IO
events, it makes it fairly easy to accidentally have unbalanced calls.

Consider for example a lock which is released either when a video
reaches its end, when the user presses the pause button, or when the
user close the <dialog> in which the video is rendered. It seems quite
easy to end up with a race where if the user close the <dialog> right
when the video ends, that release() would get called twice. Or if the
user pause the video first and then close the <dialog> that release()
would get called twice.

If there's only one subsystem of the page that uses a display lock,
then this is not a big deal. The extra call to release() would cause
an rejection, but hopefully that won't break the page.

However if there are multiple subsystems that all use a display lock,
it would mean that those subsystems might stomp on each other's
attempts at holding a display lock. The effect would be that the
display lock is released too early.

I don't care strongly about this though. It's pretty easy for pages to
write a wrapper around the currently proposed API to implement the API
that I'm proposing.

/ Jonas

Reply via email to