[whatwg] Workers feedback

[Ian Hickson]

On Sat, 16 Oct 2010, Samuel Ytterbrink wrote:
>
> *What is the problem you are trying to solve?*
> To create sophisticated single file webpages.

That's maybe a bit vaguer than I was hoping for when asking the question. :-)

Why does it have to be a single file? Would multipart MIME be acceptable?

A single file is a solution, not a problem. What is the problem?


> [...] trying to build a more optimal standalone DAISY player (would be 
> nice if i could rewrite it with web workers).

Now that's a problem. :-)

It seems like what you need is a package mechanism, not necessarily a way 
to run workers without an external script.


On Fri, 15 Oct 2010, Jonas Sicking wrote:
>
> Allowing both blob URLs and data URLs for workers sounds like a great 
> idea.

I expect we'll add these in due course, probably around the same time we 
add cross-origin workers. (We didn't add them before because exactly how 
we do them depends on how we determine origins.)


On Sat, 16 Oct 2010, Samuel Ytterbrink wrote:
> 
> But then i got another problem, why is not
> "file:///some_directory_where_the_html_are/" not the same domain as
> "file:///some_directory_where_the_html_are/child_directory_with_ajax_stuff/".
> I understand if it was not okay to go closer to root when ajax,
> "file:///where_all_secrete_stuff_are/" or "/../../".

That's not a Web problem. I recommend contacting your browser vendor about 
it. (It's probably security-related.)


On Thu, 30 Dec 2010, Glenn Maynard wrote:
> On Thu, Dec 30, 2010 at 7:11 PM, Ian Hickson <ian at hixie.ch> wrote:
> > 
> > Unfortunately we can't really require immediate failure, since there'd 
> > be no way to test it or to prove that it wasn't implemented -- a user 
> > agent could always just say "oh, it's just that we take a long time to 
> > launch the worker sometimes". (Performance can be another hardware 
> > limitation.)
> 
> Preferably, if a Worker is successfully created, the worker thread 
> starting must not block on user code taking certain actions, like 
> closing other threads.

How can you tell the difference between "the thread takes 3 seconds to 
start" and "the thread waits for the user to close a thread", if it takes 
3 seconds for the user to close a thread?

My point is from a black-box perspective, one can never firmly say that 
it's not just the browser being slow to start the thread. And we can't 
disallow the browser from being slow.


> That doesn't mean it needs to start immediately, but if I start a thread 
> and then do nothing, it's very bad for the thread to sit in limbo 
> forever because the browser expects me to take some action, without 
> anything to tell me so.

I don't disagree that it's bad. Hopefully browser vendors will agree and 
this problem will go away.


> If queuing is really necessary, please at least give us a way to query 
> whether a worker is queued.

It's queued if you asked it to start and it hasn't yet started.


On Fri, 31 Dec 2010, Aryeh Gregor wrote:
> 
> I've long thought that HTML5 should specify hardware limitations more 
> precisely.

We can't, because it depends on the hardware. For example, we can't say 
"you must be able to allocate a 1GB string" because the system might only 
have 500MB of storage.


> Clearly it can't cover all cases, and some sort of general escape clause 
> will always be needed -- but in cases where limits are likely to be low 
> enough that authors might run into them, the limit should really be 
> standardized.

It's not much of a standardised limit if there's still an escape clause.

I'm happy to put recommendations in if we have data showing certain 
specific limits are needed for interop with real content.


> > Unfortunately we can't really require immediate failure, since there'd 
> > be no way to test it or to prove that it wasn't implemented -- a user 
> > agent could always just say "oh, it's just that we take a long time to 
> > launch the worker sometimes". (Performance can be another hardware 
> > limitation.)
> 
> In principle this is so, but in practice it's not.  In real life, you 
> can easily tell an algorithm that runs the first sixteen workers and 
> then stalls any further ones until one of the early ones exit, from an 
> algorithm that just takes a while to launch workers sometimes.  I think 
> it would be entirely reasonable and would help interoperability in 
> practice if HTML5 were to require that the UA must run all pending 
> workers in some manner that doesn't allow starvation, and that if it 
> can't do so, it must return an error rather than accepting a new worker.  
> Failure to return an error should mean that the worker can be run soon, 
> in a predictable timeframe, not maybe at some indefinite point in the 
> future.

All workers should run soon, not maybe in the future. Not running a 
worker should be an unusual circumstance. Errors that occur in unusual 
circumstances aren't errors that authors will check for.

This dicussion comes from Chrome having a very small limit currently. It 
is my understanding that this limit is temporary and not representative 
of what the API will be like once widely implemented.


On Fri, 7 Jan 2011, Berend-Jan Wever wrote:
> 
> I read that giving WebWorkers access to the DOM is apparently a bad 
> idea: http://forums.whatwg.org/viewtopic.php?t=4437 However, the page 
> does not mention why. I'd like to know :)

It's basically due to limitations in how browsers are built. The DOM 
implementations have shared global state that isn't thread-safe.


On Fri, 7 Jan 2011, Berend-Jan Wever wrote:
> 
> 1) To give WebWorkers access to the DOM API so they can create their own 
> elements such as img, canvas, etc...?

It's the API itself that isn't thread-safe, unfortunately.


> 2) To create a way to communicate media data between web workers and 
> pages without serialization, so they can pass img, video, and/or audio 
> with high throughput?

You can't currently do anything with audio or video in a worker. Image 
data from canvas can be passed along, though. How fast the throughput is 
depends on the browser.


> 3) Introduce a set of "shared" objects, which are re-entrancy save 
> versions of a very limited sub-set of classes in the DOM API.

Not sure what this means.


On Thu, 13 Jan 2011, Jorge wrote:
> 
> But I think that the workers desperately need a mechanism that permitted 
> to pass objects *quickly*, and *quickly* most likely means by reference 
> not by copy.

The spec doesn't preclude browsers from implementing copy-on-write 
semantics, which essentially gives you by-reference. (We can't do actual 
by-reference without freezing values on both sides somehow, since 
otherwise you'd have race conditions.)


On Thu, 13 Jan 2011, Glenn Maynard wrote:
> 
> Browsers should be allowed to permit 0ms "return, run events then run 
> this code immediately" timers.  It takes some heuristics to do this 
> safely, to prevent code which (usually accidentally) assumes a minimum 
> delay from busy looping, but browsers should be free to attempt such a 
> heuristic, not required by spec to clamp to 4ms.

The reason the spec requires a 4ms clamp is that if you implement a 0ms 
clamp, pages break. (Note: the spec only clamps if the setTimeout() is 
called from another setTimeout().)


> Non-looping 0ms timers are common, to run code when the current call 
> finishes.

Yeah, spec allows those fine.


> Timeouts in workers shouldn't require this, either, since there's no 
> legacy code to worry about.

Keeping the timers the same everywhere is good for sanity.


On Thu, 13 Jan 2011, Boris Zbarsky wrote:
> 
> timeouts in workers are... weird as currently specced.  Not only do they 
> have the 4ms floor for nested timeouts, but they're not specced in terms 
> of wall-clock time but rather in terms of time during which the worker 
> is not suspended.

The idea being that if you have scheduled two timers to fire two seconds 
apart, and the user happens to leave the page and return, you don't want 
them all to fire at once.

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