[whatwg] Workers feedback

[Gregg Tavares (wrk)]

On Fri, Feb 4, 2011 at 3:43 PM, Ian Hickson <ian at hixie.ch> wrote:

> 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.
>

I didn't see the original thread but how is a WebWorker any different from
another webpage? Those run just fine in other threads and use the DOM API.

It seems like treating a WebWorker like another webpage without a display
would open WebWorkers to far more work. They could do GPGPU work using
WebGL. They could image process using canvas.  They could build DOM elements
using standard DOM APIs and common libraries then use innerHTML to get a
string to pass back to the calling page. It means as new stuff as added to
the DOM or new objects they don't have to be special cased for WebWorkers.





>
>
> > 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.   `._.-(,_..'--(,_..'`-.;.'
>