- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 18 Aug 2014 18:07:06 -0700
- To: Marcos Caceres <w3c@marcosc.com>
- Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Mounir Lamouri <mounir@lamouri.fr>
On Mon, Aug 18, 2014 at 4:37 PM, Marcos Caceres <w3c@marcosc.com> wrote:
>> while(navigator.wakeLock.isHeld("screen")) navigator.wakeLock.release("screen"); // just release the damn thing in my leaky code!
>
> That would just halt the browser as the script would never complete: currently releasing happens async once the system acknowledges that the release has been granted. I'm not sure if there is a use case for that behavior - it's just what is currently/sorta roughly proposed in the spec.
I don't think the sync part was the important aspect here. You could
easily rewrite that as an async loop.
The point is that it's easy for developers to end up trying to work
around bugs in their own code by simply doing extra releases. Or end
up with bugs where they accidentally release too many times and so
stomp on other components.
>> Therefore, if WakeLock needs to be purely JS API, I strongly prefer having WakeLock available only as an object instance, but without exposing GC behavior--if it's lost, it's like a missing release call.
>>
>> If devtools ever get monitoring of unhanded errors in Promise objects, they could also warn against lost WakeLock objects--it's the same type of problem dependent on GC.
>>
>> I'm assuming that release would work only once on each lock object:
>>
>> var lock = new WakeLock("screen");
>> lock.release();
>> lock.release(); // ignored, so it doesn't unlock any other component's lock
>>
>> This makes coordination easier: each page component can easily create their own lock independently (without needing to create an iframe to get their own lock), and can't release any other component's lock.
>
> Personally, I don't know if I agree that it makes coordination easier. Seems that having a centralized place to check what is currently being held makes life a lot easier, because it allows scripts to check if they actually need to request a lock or not.
Why does the ability to check if a lock is held make coordination
easier? Checking if they need to request a lock or if someone else is
already doing it seems like a very bad code pattern which actually
makes coordination harder. It makes it very easy to get confused and
try to rely on party X to hold a lock, but then it turns out that in
reality it was Y holding the lock, but Y releases the lock much sooner
and now end up holding a lock for a shorter time than intended.
Am I missing something?
> If you have some objects requesting and others releasing, then it makes a huge mess because you need to track down which object screwed up the lock.
This is not what the proposal is. The proposal is that if a WakeLock
instance x is used to grab a lock, then the lock will be held until
x.release() is called. Any calls on other WakeLock instances will not
cause the lock to be released. Only one all WakeLock instances that
have had request() called on them also gets a call to release(), does
the lock get released.
Losing track of the instance that you called request() on, then that
is equivalent to losing track of how many time you have called
wakeLock.request(x). There is no way to get correctly out of that
situation.
> And if GC also then works to release the locks, then there is no certainty as to what is actually releasing the lock or when.
Can we please stop talking about GC. I don't think anyone has made a
serious proposal where GC releases a lock, or where GC is otherwise
exposed.
/ Jonas
Received on Tuesday, 19 August 2014 01:08:03 UTC