[whatwg] Storage mutex

[Jeremy Orlow]

I was looking through the WebStorage and HTML 5 specs regarding the storage
mutex.  I have a few comments/questions.
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).  Should this
really say "must" instead of "may"?  IIRC (I couldn't find the original
thread, unfortunately) this was added because of deadlock concerns.  It
seems like there might be some UA implementation specific ways this could
deadlock and there is the question of whether we'd want an alert() while
holding the lock to block other execution requiring the lock, but I don't
see why the language should be "must".  For Chromium, I don't think we'll
need to release the lock for any of these, unless there's some
deadlock scenario I'm missing here.

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.  If there were some place to mention this as a "may" type thing,
it'd be good, but I realize it's probably out of scope for HTML 5.

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?  A normal event isn't going to be of much use, since it'll fire
after the scripts execution ends (so the lock would have been dropped by
then anyway).  A boolean doesn't seem super useful, but it's better than
nothing and could help debugging.  Maybe fire an exception?  Are there other
options?

Lastly, is navigator.getStorageUpdates() the right name for the function
that drops the lock?  Why was it changed from navigator.releaseLock()?  I
assume we're trying to avoid the word "lock", but the reason why you'd need
to call a function to get updates is not clear without understanding the
concept of a lock...so what's the point of making this so cryptic?

Thanks,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090818/60dff912/attachment.htm>