[whatwg] Worker feedback

On Sat, 28 Mar 2009, Robert O'Callahan wrote:
> On Sat, Mar 28, 2009 at 2:23 PM, Ian Hickson <ian at hixie.ch> wrote:
> > Robert O'Callahan wrote:
> > > Now, with the storage mutex, are there any cases you know of where 
> > > serializability fails? If there are, it may be worth noting them in 
> > > the spec. If there aren't, why not simply write serializability into 
> > > the spec?
> >
> > Just writing that something must be true doesn't make it true. :-) I 
> > think it's safer for us to make the design explicitly enforce this 
> > rather than say that browser vendors must figure out where it might be 
> > broken and enforce it themselves.
> 
> If serializability is the goal then I think it can only help to say so 
> in the spec (in addition to whatever "explicit design" you wish to 
> include), so that any failure of serializability is clearly an 
> inconsistency in the spec that must be fixed rather than a loophole that 
> authors and browser vendors might think they can rely on.

Done.


> I also suggest that speccing just serializability should be fine.

The problem is that this is specifying an "anti-requirement", which 
doesn't really help in defining what the behaviour _should_ be like. It 
doesn't tell us what the order of events should be, for instance, just 
that some order should exist.


> It seems to me the current spec is proposing one implementation of 
> serializability while other implementations are possible, and relying on 
> the black-box equivalence principle to enable other implementations. But 
> specifying serializability is probably simpler and may allow 
> implementations that are unintentionally ruled out by the "explicit 
> design" in the spec, especially as things become more complicated in the 
> future. It would probably also be clearer to authors what they can 
> expect.

What kind of implementations are unintentionally ruled out that you think 
should not be ruled out?


> I think it's a lot like GC; we don't specify a GC algorithm, even though 
> GC is hard; we just have an implicit specification that objects don't 
> disappear arbitrarily.

It's explicit now, actually (see 2.9.8 Garbage collection, 5.3.5 Garbage 
collection and browsing contexts, 7.3.3.1 Ports and garbage collection, 
and similar sections in the Event Source, Workers, and Web Sockets specs).


On Sat, 28 Mar 2009, Alexey Proskuryakov wrote:
> On 28.03.2009, at 4:23, Ian Hickson wrote:
> > 
> > I think, given text/css, text/html, and text/xml all have character 
> > encoding declarations inline, transcoding is not going to work in 
> > practice. I think the better solution would be to remove the rules 
> > that make text/* an issue in the standards world (it's not an issue in 
> > the "real" world).
> 
> In fact, transcoding did work in practice - that's because HTTP headers 
> override inline character declarations.

It worked for as long as the HTTP override was around to override, but as 
soon as the user saves the file to disk, or some such, it fails.


> > For new formats, though, I think just supporting UTF-8 is a big win.
> 
> Could you please clarify what the win is?

It's massively simpler to not have to deal with the horrors of character 
encodings.


> Disregarding charset from HTTP headers is just a weird special case for 
> a few text resource types. If we were going to deprecate HTML, XML and 
> CSS, but keep appcache manifest going forward, it could maybe make 
> sense.

What's the advantage of introducing all the pain and suffering that 
encodings will inevitably bring with them to the cache manifest format?



On Sat, 28 Mar 2009, Kristof Zelechovski wrote:
>
> Scripts, and worker scripts in particular, should use application media 
> type; using text/javascript is obsolete. [RFC4329#3].

IMHO RFC4329 is silly.


On Mon, 30 Mar 2009, Drew Wilson wrote:
>
> In the past we've discussed having synchronous APIs for structured 
> storage that only workers can use - it's a much more convenient API, 
> particularly for applications porting to HTML5 structured storage from 
> gears. It sounds like if we want to support these APIs in workers, we'd 
> need to enforce the same kind of serializability guarantees that we have 
> for localStorage in browser windows (i.e. add some kind of structured 
> storage mutex similar to the localStorage mutex).

This API now exists.

I don't think it causes any particular serialization problems, the only 
issue seems to be what happens if a worker grabs the write lock to a 
database and then doesn't release it, but then all it will do is cause the 
browsing contexts that are waiting for that lock to just never call the 
relevant callback (and for the sync workers from that domain to block), so 
it doesn't seem like a huge deal. (It's still serialisable, it's just 
there's a big wait in there!)



> > Re: cookies I suppose that network activity should also wait for the 
> > lock. I've made that happen.
> 
> Seems like that would restrict parallelism between network loads and 
> executing javascript, which seems like the wrong direction to go.

I agree that it's suboptimal, but given the desire for serializability, I 
don't know what to do about it.


> It feels like we are jumping through hoops to protect running script 
> from having document.cookies modified out from underneath it, and now 
> some of the ramifications may have real performance impacts. From a 
> pragmatic point of view, I just want to remind people that many current 
> browsers do not make these types of guarantees about document.cookies, 
> and yet the tubes have not imploded.

...that we know of. As Robert pointed out, this is not a bug that will be 
reported, or if it is reported, not one that will mention the root cause.

I have had experiences with IE that have led me to not use IE as my main 
browser because of inexplicable annoyances and strange behavior which 
could well be some strange race conditions. I don't know.


On Fri, 3 Apr 2009, Jeremy Orlow wrote:
> 
> After thinking about it for a bit, your suggestion of "reading the 
> cookies to send with an HTTP request is an atomic operation, and writing 
> them as a result of an HTTP response is an atomic operation" does seems 
> like a pretty sensible compromise.

That's what the (HTML5) spec requires now. (Well, it doesn't talk about 
reading, that's implicitly atomic.)


On Mon, 6 Apr 2009, Michael Nordman wrote:
>
> There are additional constraints that haven't been mentioned yet... 
> Plugins.
> 
> The current model for plugins is that they execute in a single-threaded 
> world. Chrome maintains that model by hosting each plugin in its own 
> process and RPC'ing method invocations back and forth between calling 
> pages and the plugin instances. All plugin instances (of a given plugin) 
> reside on the same thread.
> 
> Consider three threads
> 
> PageA
> PageB
> PluginC
> 
> PageA
> -grabs storage lock
> 
> PluginC
> -calls out to PageB (everything in NPAPI is synchronous)
> -now waiting for PageB to return
> 
> PageB
> -while handling the plugins callback, attempts to grab the storage lock
> -BLOCKED waiting for PageA to release it
> 
> PageA
> -calls plugin (sync method call)
> -BLOCK waiting indirectly for PageB
> 
> == DEADLOCK

I've added a note to the spec that any calls into or out of a plugin also 
release the storage mutex.



On Mon, 30 Mar 2009, Michael Nordman wrote:
> 
> Sounds good. I'd phrase it a little differently though. Dedicated worker 
> do have a browsing context that is distinct from their parents, but the 
> appcache selected for a dedicated worker context is identical to the 
> appacache selected for the parents context.

Do you mean the phrasing in the spec should be changed?


> Ultimately, I suspect that additionally allowing workers to specify a 
> manifest using some sort of syntax may be the right answer. That would 
> put cache selection for shared workers on par with how cache selection 
> works for pages (not just images) opened via window.open. As 'page' 
> cache selection is refined due to experience with this system, those 
> same refinements would also apply to 'shared worker' cache selection.

Yeah, that might make sense. I'd rather get implementation experience from 
regular appcaches before adding more ways to invoke them though, lest we 
dig ourselves a hole too deep to climb back out of.

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

Received on Tuesday, 28 April 2009 19:05:03 UTC