[whatwg] Storage mutex feedback

[Ian Hickson]

On Tue, 18 Aug 2009, Jeremy Orlow wrote:
>
> First of all, I was wondering why all user prompts are specified as 
> "must release the storage mutex" ( 
> http://dev.w3.org/html5/spec/Overview.html#user-prompts).

This is because otherwise, if the script has the storage mutex, the user 
can't open any new pages in the entire browser app from any sites that set 
cookies, until he has dismissed the alert. This would prevent him from, 
for instance, going to a URL listed in the alert to check something before 
dismissing the alert.


> It seems like there might be some UA implementation specific ways this 
> could deadlock

I'm not aware of any implementation-specific issues with the storage mutex 
that are black-box detectable.


> I don't see why the language should be "must".

The idea is to make sure all the browsers do the same thing.


> It's also worth noting that Chromium is probably going to need to drop 
> the storage mutex for most if not all plugin related calls due to 
> deadlock conditions.

This is required already by the spec.


> Given that different UAs are probably going to have other scenarios 
> where they have to drop the lock (some of them may even be purely 
> implementational issues), should we add some way for us to notify 
> scripts the lock was dropped?

Could you list some examples of such cases? I'm not aware of any such 
cases at the moment.

I'd rather not expose the lock to authors at all, if we can avoid doing 
so.


> Lastly, is navigator.getStorageUpdates() the right name for the function 
> that drops the lock?  Why was it changed from navigator.releaseLock()?  

"What lock?" Authors won't know anything about the storage mutex, so we 
have to describe what the method will appear to do from their perspective.


On Sat, 22 Aug 2009, Jeremy Orlow wrote:
> 
> [...] shouldn't it be left up to the UAs what to do?

Generally speaking we want to leave as little black-box detectable 
behaviour as possible undefined.


On Tue, 25 Aug 2009, Jeremy Orlow wrote:
> 
> I guess it would depend on the use.  Let's say a library/framework 
> dependeds on the lock being held but does a callback (that might do 
> something that causes the lock to be dropped).  It could check the 
> counter and raise an exception.  It could also re-start "processing" if 
> that were an acceptable answer (but by having the counter, it would only 
> do so when necessary).  I think it'll be very application specific 
> _what_ you do when you catch such an error, but I do think it'll be 
> valuable to developers.

If you can come up with a viable scenario that would need such a feature, 
then it's worth considering. However, so far it's been mostly a 
theoretical concern. I'd rather not add anything to do with this feature 
if we can avoid it, since we'd like to find a way to drop the whole thing 
in the future, and we want to allow implementors to do optimisations that 
might break assumptions we might make in any API we expose.


On Tue, 25 Aug 2009, Drew Wilson wrote:
> 
> The problem with leaving this up to the UA is it becomes a point of 
> incompatibility - on one browser, it's safe to put up an alert, on 
> another it isn't. So if applications have to fall back to the LCD 
> behavior, then we might as well codify it in the spec, which we have :)

Indeed.


On Tue, 25 Aug 2009, Jeremy Orlow wrote:
>
> What about yieldStorageMutex?  Yield is enough different from unlock 
> that I don't think it'll leave developers looking for the lock function.  
> Yield fits pretty well since this is essentially cooperative 
> multi-tasking.

yieldForStorageUpdates() maybe?


> StorageMutex is good because that's what its actually affecting.

Yeah but that's what we want to hide from the author. Only people who read 
the spec with a fine tooth comb are going to know anything about the 
storage mutex.


On Wed, 26 Aug 2009, Jens Alfke wrote:
> 
> (At a higher level, though, I'm still uncomfortable with semantics that 
> allow a poorly-written worker thread to indefinitely lock up JS code 
> running in web pages.)

Workers can't get the storage mutex.


On Fri, 28 Aug 2009, Kevin Benson wrote:
> 
> How about:
> 
> commitStorageUpdates
> 
> ... since a new transactor cannot write to storage until a commit point 
> is reached by the current transactor finishing up and releasing the 
> lock.

That could work too.


Upon further consideration I've renamed getStorageUpdates() to 
yieldForStorageUpdates().


On Fri, 28 Aug 2009, Jeremy Orlow wrote:
> 
> One question about this, actually.  I'm a bit troubled by the following 
> language:
> 
> "Whenever a script calls into a plugin, and whenever a plugin calls into 
> a script, the user agent must release the storage mutex."
> 
> Can a plugin ever call into a script while a script is running besides 
> when the script is making a synchronous call to the plugin?  If so, that 
> worries me since it'd be a way for the script to lose its lock at _any_ 
> time.

The HTML5 spec doesn't say what plugins can do, so yes, theoretically a 
plugin could call in whenever it wants. (I don't know if that applies to 
NPAPI plugins.)

Plugins in general have to come with documentation that says how they 
work. All bets are off when a plugin is involved. I wouldn't worry about 
it with respect to this issue.


On Wed, 26 Aug 2009, Darin Fisher wrote:
> On Wed, Aug 26, 2009 at 12:49 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
> > On Wed, Aug 26, 2009 at 11:17 AM, Darin Fisher <darin at chromium.org> wrote:
> >> On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow <jorlow at chromium.org>wrote:
> >>> On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher <darin at chromium.org>wrote:
> >>>> On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> >>>>
> >>>>> That behaviour sounds worse than what Firefox currently does, 
> >>>>> where an alert disables input to all tabs in the window (which is 
> >>>>> already pretty bad), because it willl make applications in 
> >>>>> visually unrelated tabs and windows hang.
> >>>>
> >>>> You can have script connections that span multiple tabs in multiple 
> >>>> windows, so in order to preserve the run-to-completion semantics of 
> >>>> JavaScript, it is important that 
> >>>> window.{alert,confirm,prompt,showModalDialog} be modal across all 
> >>>> windows in the browser.  This is why those APIs suck rocks, and we 
> >>>> should never create APIs like them again.
> >>>
> >>> I don't understand your point here.  Are you saying that the current 
> >>> firefox behavior is not correct, that releasing the storage lock on 
> >>> these events is not correct, or something else?
> >>
> >> I meant that the current Firefox behavior is technically incorrect.  
> >> No one likes app modal dialogs, but how else can you guarantee 
> >> run-to-completion semantics? How else do you prevent other scripts 
> >> from modifying your state while you are stuck calling into 
> >> window.alert().
> >
> > I don't know much about this issue, but it seems like something that 
> > should either be fixed in Firefox (and other browsers?) or changed in 
> > the spec.
> 
> Chrome and Safari both implement app-modal alerts.  Firefox and IE 
> implement window modal, which is clearly buggy, but of course the world 
> hasn't imploded.  I haven't tested Opera.
> 
> Personally, I would like to change Chrome to not put up app modal 
> alerts.  I think it is bad UI, but I'm not sure how to do so without 
> also breaking the contract that JavaScript execution appear single 
> threaded.

HTML5 requires that alert() block everything on its thread. (It pauses the 
event loop of the script that is using alert(), which causes all events, 
including user interaction events and timers, to stop being processed on 
that thread.)


On Wed, 26 Aug 2009, Jens Alfke wrote:
> 
> However, there's a scenario under the current spec that doesn't involve 
> local storage, whereby a worker thread can deadlock the browser. This is 
> because access to cookies, by workers or the browser itself, is also 
> subject to that global mutex.

Workers can't access cookies.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'