[whatwg] Web Workers feedback

[Simon Pieters]

On Tue, 30 Mar 2010 23:09:49 +0100, Ian Hickson <ian at hixie.ch> 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 <img> in, and for that there isn't really a fallback position,
> so it doesn't matter if we send null or throw an exception.

It does matter because if you send null, the worker has to respond that it  
got null so the script can do what it wants on the main thread, which  
makes the operation async and means the worker script needs logic for the  
non-supported case. It's more convenient to catch an exception and do what  
you want directly, and have the worker script only care about the  
supported case.

This is actually the exact same problem as what we have now, moving from  
string based to structured clone. In order to test structured clone  
support, you have to send a message back and forth. I think it would have  
been better if non-strings threw an exception from the start, but it's too  
late to change it now.

A use case I had with structured clone is posting three ImageData objects  
where the worker compares the pixels of two of them and puts the  
difference on the third and posts that one back. I do it in a worker  
because it's a heavy operation for big images and I needed to keep the  
timing correct for events in the main thread. If workers isn't supported,  
I did the operation later when the timing of events didn't matter. I  
didn't make it detect support for workers but lack of structured clone  
because it seemed too annoying to implement.

-- 
Simon Pieters
Opera Software