[whatwg] Web Workers

Web Workers offer reliability and performance benefits on multi-core CPUs to a certain class of parallelisable tasks that are primarily concerned with raw computation over data access. It can clearly be seen that the lower the ratio of data access to raw computation, the more performance benefits t

[whatwg] Web Workers feedback

On Thu, 10 Dec 2009, Simon Pieters wrote: > > Web Workers says in the SharedWorker constructor algorithm: > > "Otherwise, if name is the empty string and there exists a > SharedWorkerGlobalScope object whose closing flag is false, and whose > location attribute is exactly equal to scriptURL, the

[whatwg] Web Workers feedback

On Tue, 30 Mar 2010, Jonas Sicking wrote: > > > > My understanding was that relying on exceptions for non-exceptional > > cases is bad API design. Why would it be ok here? > > I think fallback is to be considered an exceptional case. Especially as > time goes on and more browsers implement suppo

[whatwg] Web Workers API

Hi, The IDL for Worker in the Web Workers API specification shows: void postMessage(in any message, in optional MessagePortArray ports); I have a question regarding the 'any' type for message. If a caller of postMessage passes an object to a worker that is not a string, is it converted to a

Re: [whatwg] Web Workers

On Wed, Jul 21, 2010 at 1:11 PM, Ryan Heise wrote: > > > For all of the reasons above, I would like to see something like threads > in Javascript. Yes, threads give rise to race conditions and deadlocks, > but this seems to be in line with Javascript's apparent philosophy of > doing very little st

Re: [whatwg] Web Workers

On 7/21/10 4:11 PM, Ryan Heise wrote: > Note that things might have been different had Javascript been a > purely functional language. If this were the case, then there would > be much safer and more efficient alternatives to making whole copies > of data that could be implemented under the hood.

Re: [whatwg] Web Workers

Drew Wilson wrote: > Rather than trying to shoehorn concurrent functionality into Javascript (where > many implementations don't support multi-threaded access down at the VM level > anyway, so the obstacles to implementation seem fairly large) it seems like a > better option is to use a different

Re: [whatwg] Web Workers

On 7/22/10 3:21 AM, Ryan Heise wrote: Note also that said engines are removing said support for various reasons (performance penalties are a large part of it). Clearly, it has been shown possible to implement threads efficiently in other languages The current browser competitive landscape is

Re: [whatwg] Web Workers

On Thu, 22 Jul 2010, Ryan Heise wrote: > > [...] For all of the reasons above, I would like to see something like > threads in Javascript. Yes, threads give rise to race conditions and > deadlocks, but this seems to be in line with Javascript's apparent > philosophy of doing very little static

[whatwg] Web Workers Draft

Hello, I was taking a look at the Web Workers Draft ( http://www.whatwg.org/specs/web-workers/current-work/ ), and I couldn't find any mention of cross domain workers. I've read a bit about relaxing domain restrictions on documents, but worker's don't seem to have a document object. I als

[whatwg] Web Workers: Worker.onmessage

Shouldn't setting onmessage on a Worker object enable the port message queue? Currently step 8 of the "run a worker" algorithm enables the port message queue for the WorkerGlobalObjectScope side, but it is never enabled when going in the other direction, if I'm reading the spec correctly.

Re: [whatwg] Web Workers feedback

On Thu, 25 Mar 2010 01:51:42 +0100, Ian Hickson wrote: On Tue, 23 Feb 2010, Simon Pieters wrote: The Web Worker's first example of shared workers is quite involved and not so easy to follow if you haven't dealt with shared workers before. For someone wanting to experiment with shared workers,

Re: [whatwg] Web Workers feedback

> On Mon, 1 Mar 2010, ben turner wrote: >> >> I'm implementing the structured clone algorithm and this part bothers me >> a little bit: >> >>   - If input is a host object (e.g. a DOM node) >>       Return the null value. >> >> Seems like this has the potential to confuse web programmers somewhat.

Re: [whatwg] Web Workers feedback

On Mon, 29 Mar 2010, Jonas Sicking wrote: > > > > We could throw an exception, but that would make migrating from this > > not being supported to this being supported later a lot harder (you'd > > have to catch exceptions and then remove the nodes, rather than just > > doing null checks in the w

Re: [whatwg] Web Workers feedback

On Tue, Mar 30, 2010 at 12:20 AM, Ian Hickson wrote: > On Mon, 29 Mar 2010, Jonas Sicking wrote: >> > >> > We could throw an exception, but that would make migrating from this >> > not being supported to this being supported later a lot harder (you'd >> > have to catch exceptions and then remove t

Re: [whatwg] Web Workers feedback

On 3/30/2010 09:54, Jonas Sicking wrote: > On Tue, Mar 30, 2010 at 12:20 AM, Ian Hickson wrote: > >> On Mon, 29 Mar 2010, Jonas Sicking wrote: >> >> ... >>> Additionally, it's unlikely that converting to null is the fallback >>> behavior you want for downlevel clients. Likely you'd want to

Re: [whatwg] Web Workers feedback

On Tue, 30 Mar 2010, Jonas Sicking wrote: > > > > I agree that people are less likely to depend on exceptions. The > > problem is feature detection so that you can use the new feature > > (sending DOM nodes) in new clients without failing in old clients. > > When sending null it's easy; when rai

Re: [whatwg] Web Workers feedback

On Tue, Mar 30, 2010 at 3:09 PM, Ian Hickson wrote: > On Tue, 30 Mar 2010, Jonas Sicking wrote: >> > >> > I agree that people are less likely to depend on exceptions. The >> > problem is feature detection so that you can use the new feature >> > (sending DOM nodes) in new clients without failing i

Re: [whatwg] Web Workers feedback

On Tue, 30 Mar 2010 15:09:49 -0700, Ian Hickson wrote: On Tue, 30 Mar 2010, Jonas Sicking wrote: Personally my guess it's more likely that they really wanted to. I have no idea which is more likely. The only use case I'm aware of is passing an in, and for that there isn't really a fallback p

Re: [whatwg] Web Workers feedback

On Wed, 31 Mar 2010, Anne van Kesteren wrote: > On Tue, 30 Mar 2010 15:09:49 -0700, Ian Hickson wrote: > > On Tue, 30 Mar 2010, Jonas Sicking wrote: > > > Personally my guess it's more likely that they really wanted to. > > > > I have no idea which is more likely. The only use case I'm aware of i

Re: [whatwg] Web Workers feedback

On Tue, 30 Mar 2010 23:09:49 +0100, Ian Hickson wrote: Personally my guess it's more likely that they really wanted to. I have no idea which is more likely. The only use case I'm aware of is passing an in, and for that there isn't really a fallback position, so it doesn't matter if we send n

Re: [whatwg] Web Workers feedback

FYI: as of now, WebKit Workers 'close()' behavior is following the results of this thread and is compatible with FF (except we don't implement close event, as mentioned here). Thanks for clarifications! Dmitry On Fri, Apr 16, 2010 at 6:06 PM, Ian Hickson wrote: > On Tue, 30 Mar 2010, Jonas Sic

Re: [whatwg] Web Workers API

All meesaging through postMessage uses the internal structured cloning algorithm detailed at http://www.w3.org/TR/2010/WD-html5-20100304/Overview.html#internal-structured-cloning-algorithm It's basically a deep copy, but has a few restrictions on the types cloned, and doesn't copy functions or

Re: [whatwg] Web Workers Draft

On Tue, Dec 9, 2008 at 3:42 PM, Douglas Mayle wrote: > Hello, >I was taking a look at the Web Workers Draft ( > http://www.whatwg.org/specs/web-workers/current-work/ ), and I couldn't find > any mention of cross domain workers. I've read a bit about relaxing domain > restrictions on docume

Re: [whatwg] Web Workers Draft

After sending this, it occurs to me that at the worst, I could have a separate document to marshal access to a cross domain web worker. It's an extra hoop to jump through, but at least it would work. Douglas Mayle The Open Planning Project http://topp.openplans.org On Dec 9, 2008, at 9:42 A

Re: [whatwg] Web Workers Draft

On Tue, 9 Dec 2008, Douglas Mayle wrote: > > I was taking a look at the Web Workers Draft ( > http://www.whatwg.org/specs/web-workers/current-work/ ), and I couldn't > find any mention of cross domain workers. I've read a bit about > relaxing domain restrictions on documents, but worker's don't

[whatwg] Web Workers: minor issues

showNotification is no longer part of HTML5. The SharedWorker IDL block uses . That should probably be . Why is everything a NoInterfaceObject? Doesn't that mean that you can no longer prototype them? -- Anne van Kesteren

[whatwg] Web Workers: "SyntaxError exception"?

Web Workers says "If it failed to parse, then throw a SyntaxError exception and abort all these steps." Shouldn't that be SYNTAX_ERR exception? -- Simon Pieters Opera Software

Re: [whatwg] Web Workers: Worker.onmessage

On Wed, 11 Nov 2009 16:05:53 +0100, Simon Pieters wrote: Shouldn't setting onmessage on a Worker object enable the port message queue? Currently step 8 of the "run a worker" algorithm enables the port message queue for the WorkerGlobalObjectScope side, but it is never enabled when going

Re: [whatwg] Web Workers: Worker.onmessage

On Wed, 11 Nov 2009, Simon Pieters wrote: > On Wed, 11 Nov 2009 16:05:53 +0100, Simon Pieters wrote: > > > > Shouldn't setting onmessage on a Worker object enable the port message > > queue? > > > > Currently step 8 of the "run a worker" algorithm enables the port > > message queue for the Wor

[whatwg] Web Workers and MessagePort feedback

I'm still digesting the Web Worker proposal, but here is some feedback. Sorry it is a bit long. Structural API stuff: - I still haven't really internalized the need to either have workers speak directly to anyone other than the person who created them, or the other use cases that MessageChannels

Re: [whatwg] Web Workers: minor issues

On Wed, 7 Jan 2009, Anne van Kesteren wrote: > > showNotification is no longer part of HTML5. Fixed. > The SharedWorker IDL block uses . That should probably be . Fixed. > Why is everything a NoInterfaceObject? Doesn't that mean that you can no > longer prototype them? I've updated all the

[whatwg] Web Workers and postMessage(): Questions

Hi all, I've been writing some code that uses web workers. It's a very nice addition to the HTML toolbox (kudos!), but I have some questions: First, why does the structured clone algorithm used by postMessage() [1] throw an exception if it encounters cycles? It seems to me that the memory-based l

Re: [whatwg] Web Workers: "SyntaxError exception"?

On Tue, 3 Nov 2009, Simon Pieters wrote: > > Web Workers says > > "If it failed to parse, then throw a SyntaxError exception and abort all > these steps." > > Shouldn't that be SYNTAX_ERR exception? No, it's trying to emulate eval(). -- Ian Hickson U+1047E)\._.,-

Re: [whatwg] Web Workers and MessagePort feedback

Aaron Boodman wrote: I'm still digesting the Web Worker proposal, but here is some feedback. Sorry it is a bit long. Structural API stuff: - I still haven't really internalized the need to either have workers speak directly to anyone other than the person who created them, or the other use cas

Re: [whatwg] Web Workers and MessagePort feedback

Thanks for the quick reply... On Tue, Aug 5, 2008 at 2:52 PM, Jonas Sicking <[EMAIL PROTECTED]> wrote: >> I know this is weird wrt GC when combined with MessagePorts, and I >> don't have a proposed solution. > > I don't think we should say much regarding GC at all. All we should say is > that GC s

Re: [whatwg] Web Workers and postMessage(): Questions

On Wed, 22 Jul 2009, Daniel Gredler wrote: > > First, why does the structured clone algorithm used by postMessage() [1] > throw an exception if it encounters cycles? It seems to me that the > memory-based logic which is used to catch cycles could easily be > modified to resolve them instead. Th

Re: [whatwg] Web Workers and postMessage(): Questions

On Sat, Aug 1, 2009 at 4:59 PM, Ian Hickson wrote: > On Wed, 22 Jul 2009, Daniel Gredler wrote: > > > > First, why does the structured clone algorithm used by postMessage() [1] > > throw an exception if it encounters cycles? It seems to me that the > > memory-based logic which is used to catch cy

Re: [whatwg] Web Workers and postMessage(): Questions

On Mon, Aug 3, 2009 at 10:34 AM, Daniel Gredler wrote: > >> I know Anne VK (Opera) and ROC (Mozilla) appear to read this list... any > comments, guys? Should I just file bugs? Any Safari / Chrome / IE guys out > there with comments? > I've often had the same thought (that there's no reason we sho

Re: [whatwg] Web Workers and postMessage(): Questions

On Mon, 03 Aug 2009 19:47:14 +0200, Maciej Stachowiak wrote: > I'd prefer to stick with JSONic object graphs for now. Correctly > cloning more complicated object structures is a fair bit more > complicated, so I'd like to get solid interop on the basic cases > first. Also, the idea is that postMes

Re: [whatwg] Web Workers and postMessage(): Questions

On Aug 3, 2009, at 10:34 AM, Daniel Gredler wrote: On Sat, Aug 1, 2009 at 4:59 PM, Ian Hickson wrote: On Wed, 22 Jul 2009, Daniel Gredler wrote: > > First, why does the structured clone algorithm used by postMessage() [1] > throw an exception if it encounters cycles? It seems to me that th

Re: [whatwg] Web Workers and postMessage(): Questions

On Tue, Aug 4, 2009 at 5:34 AM, Daniel Gredler wrote: > I know Anne VK (Opera) and ROC (Mozilla) appear to read this list... any > comments, guys? Should I just file bugs? Any Safari / Chrome / IE guys out > there with comments? I know very little about these issues. Jonas Sicking reads this lis

Re: [whatwg] Web Workers and postMessage(): Questions

On Mon, Aug 3, 2009 at 4:14 PM, Robert O'Callahan wrote: > On Tue, Aug 4, 2009 at 5:34 AM, Daniel Gredler > wrote: >> >> I know Anne VK (Opera) and ROC (Mozilla) appear to read this list... any >> comments, guys? Should I just file bugs? Any Safari / Chrome / IE guys out >> there with comments? >

Re: [whatwg] Web Workers and postMessage(): Questions

On Mon, 3 Aug 2009, Daniel Gredler wrote: > On Sat, Aug 1, 2009 at 4:59 PM, Ian Hickson wrote: > > On Wed, 22 Jul 2009, Daniel Gredler wrote: > > > Second, why not walk the prototype chain? Similar rules regarding > > > host objects and regular objects could apply to prototypes. You > > > would

[whatwg] Web Workers: include simple example for shared workers

The Web Worker's first example of shared workers is quite involved and not so easy to follow if you haven't dealt with shared workers before. For someone wanting to experiment with shared workers, it's easier to grasp how things work by doing something very basic first. It would be useful if

Re: [whatwg] Web Workers: include simple example for shared workers

On Tue, 23 Feb 2010 21:36:15 +0100, Simon Pieters wrote: step 3. test.html Log: var worker = new SharedWorker('test.js'); var log = document.getElementById('log'); worker.port.addEventListener('message', function(e) { log.textContent += '\n' + e.data; }, false); worker.port.start(); worker

Re: [whatwg] Web Workers: include simple example for shared workers

On Thu, 25 Feb 2010 18:58:37 +0100, Drew Wilson wrote: BTW, I think it's valuable to point out in the example that MessageEvent.target == the port that received the message (so we don't need to use a closure as in the example below - just use event.target.postMessage()). Yes, I think usi

[whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case

Hi, This is a new proposal taking into account the feedback I recieved to the "[WebWorkers] About the delegation example" message. In the delegation example of the WebWorker spec, we can see this line : "var num_workers = 10;" My concern is about the arbitrarity of the "10". Regarding the hardwa

Re: [whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case

On 11/11/09 10:19 PM, David Bruant wrote: This attribute have the following properties : - It's only dependant on the hardware, the operating system and the WebWorker implementation (thus, it is not dynamically computed by the user agent at each call and two calls in the same hardware//OS//WebWor

Re: [whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case

Boris Zbarsky a écrit : > On 11/11/09 10:19 PM, David Bruant wrote: >> This attribute have the following properties : >> - It's only dependant on the hardware, the operating system and the >> WebWorker implementation (thus, it is not dynamically computed by the >> user agent at each call and two ca

Re: [whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case

On 11/12/09 12:49 PM, David Bruant wrote: => You're perfectly right. I reformulate the definition of "running conditions" (appearing in condition 2 and 3) as : "same memory available, same number of process running concurrently, no other worker running working on the same document". That doesn

Re: [whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case

Boris Zbarsky a écrit : > On 11/12/09 12:49 PM, David Bruant wrote: >> => You're perfectly right. I reformulate the definition of "running >> conditions" (appearing in condition 2 and 3) as : >> "same memory available, same number of process running concurrently, no >> other worker running working

Re: [whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case

On 11/12/09 3:40 PM, David Bruant wrote: => If you are comparing "no other processes running" and "one other process which is also completely cpu-bound running", you are not in what I've called "same running conditions". (because the number of concurrent processes is different). Yes, but your

Re: [whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case

Boris Zbarsky a écrit : > On 11/12/09 3:40 PM, David Bruant wrote: >> I reformulate this way the conditions 2 and 3: >> - In "blank conditions" (no other processes/thread running on the CPU, >> enough memory to allocate the workers), running the same algorithm (an >> easy delegation algorithm) has

Re: [whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case

On 11/12/09 7:24 PM, David Bruant wrote: => I think it happens very often. While I'm writing this e-mail, "no process" is running. About fifty processes are runnable, but not running. They are passively waiting. My CPU is barely used. Interesting. I have several browser processes using timesl

Re: [whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case

On Wed, 11 Nov 2009, David Bruant wrote: > > This is a new proposal taking into account the feedback I recieved to > the "[WebWorkers] About the delegation example" message. > > In the delegation example of the WebWorker spec, we can see this line : > "var num_workers = 10;" > > My concern is a

Re: [whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case

Ian Hickson a écrit : > On Wed, 11 Nov 2009, David Bruant wrote: > >> This is a new proposal taking into account the feedback I recieved to >> the "[WebWorkers] About the delegation example" message. >> >> In the delegation example of the WebWorker spec, we can see this line : >> "var num_worke