Re: Sync API for workers
My reading (from the proposed APIs) is that these are only synchronous from the
Worker's PoV. If that's correct I have no real objections to such an API - the
render thread simply sees a regular message. It doesn't even need a special
API on the receiving side. If the Worker has
...
var response = postSynchronousMessage(message)
...
and the renderer has
worker.onmessage =function() { ; return foo }
There are no UI blocking hazards (other than the usual slow event handler
problem, which is already present anyway)
The only real problem I can see is along the lines of:
// Worker1
onmessage = function () { ...worker2.postSynchronousMessage(...)... }
// Worker2
onmessage = function () { ...worker1.postSynchronousMessage(...)... }
In the current implementations I imagine that this may cause difficulty, but I
don't think that there is an actual technical argument against it.
--Oliver
On Sep 1, 2012, at 1:38 PM, Rick Waldron wrote:
On Saturday, September 1, 2012 at 4:28 PM, Olli Pettay wrote:
On 09/01/2012 11:19 PM, Rick Waldron wrote:
David,
Thanks for preparing this summary—I just wanted to note that I still stand
behind my original, reality based arguments.
One comment inline..
On Saturday, September 1, 2012 at 12:49 PM, David Bruant wrote:
Hi,
A Sync API for workers is being implemented in Firefox [1].
I'd like to come back to the discussions mentionned in comment 4 of the
bug.
The original post actually describes an async API—putting the word sync
in the middle of a method or event name doesn't make it sync.
As the proposed API developed, it still retains the event handler-esque
design (https://bugzilla.mozilla.org/show_bug.cgi?id=783190#c12). All of the
terminology being used is async:
- event
- callback
- onfoo
Even Olli's proposal example is async.
https://bugzilla.mozilla.org/show_bug.cgi?id=783190#c9 (setTimeout)
If the argument is callback hell, save it—because if that's the problem
with your program, then your doing it wrong (see: node.js ecosystem).
If this API introduces any renderer process blocking, the result will be
catastrophic in the hands of inexperienced web developers.
I haven't seen any proposal which would block rendering/main/dom thread
So far, they all look async. Just calling them sync doesn't make them
sync. A sync worker API:
// really sync behaviour means blocking until this returns:
var result = rendererBlockingAPI( data );
Unless you specifically design that to stop everything and wait for a
response (renderer blocking), JavaScript will run to completion.
Rick
We've been thinking the following approaches:
Proposal 1
Parent Thread:
var w = new Worker('foo.js');
w.onsyncmessage = function(event) {
event.reply('bar');
}
Worker:
var r = postSyncMessage('foobar', null, 1000 /* timeout */);
if (r == 'bar') ..
PRO:
- It's already implemented :)
CON:
- Multiple event listeners - Multiple reply() calls. How to deal with it?
- Multiple event listeners - is this your message?
- Wrong order of the messages in worker if parent sends async message just
before receiving sync message
- The message must be read in order to reply
Proposal 1.1
Parent Thread:
var w = new Worker('foo.js');
w.onsyncmessage = function(event) {
var r = new Reply(event);
r.reply(bar); // Can be called after event dispatch.
}
Worker:
var replies = postSyncMessage('foobar', null, 1000 /* timeout */);
for (var r in replies) {
handleEachReply(r);
}
PRO:
- Can handle multiple replies.
- No awkward limitations on main thread because of reply handling
CON:
- A bit ugly.
- Reply on the worker thread becomes an array - unintuitive
- Wrong order of the messages in worker if parent sends async message just
before receiving sync message
- The Reply object must be created during event dispatch.
Proposal 2
Parent Thread:
var w = new Worker('foo.js');
w.setSyncHandler('typeFoobar', function(message) {
return 'bar';
});
Worker:
var r = postSyncMessage('typeFoobar', 'foobar', null, 1000 /* timeout */);
if (r == 'bar') ..
PRO:
- no multple replyies are possible
- types for sync messages
CON:
- Just a single listener
- It's not based on event - it's something different compare with any other
worker/parent communication.
- Wrong order of the messages in worker if parent sends async message just
before receiving sync message
Proposal 3
Worker:
postMessage(I want reply to this);
var events = [];
while (var m = waitForMessage()) {
if (m.data != /* the reply * /) {
events.push(m);
} else {
// do something with message
}
}
while (events.length()) {
dispatchEvent(events.shift());
}
PRO:
- Flexible
- the order of the events is changed by the developer
- since there isn't any special sync messaging, multiple event listeners
don't
cause problems.
CON:
- complex for web developers(?)
- The message must be read in order to reply
- Means that
Re: SpellCheck API?
This is the privacy violation, and not acceptable as such. I wonder how to not expose native spellchecker data to web page, yet support this use case. Or do we need yet another permission, which user has to give to the page before the spellchecker API fully working. In general permission dialogs are not real solutions to privacy problems -- when a user sees a dialog their mindset is not what is this dialog asking? but how do i make this dialog go away?. This same problem exists with the geolocation apis and others, but adding more examples of this doesn't seem like future proof plan. --Oliver
Re: continue as a reserved word and a conflict with IndexedDB
This should work fine in a nightly already, if it doesn't you need to file a bug. --Oliver On Dec 6, 2010, at 3:08 AM, Jeremy Orlow wrote: I'm pretty sure this was discussed and that EMCA5 does make it possible to use continue as we do. At least that's the conclusion we had with delete. My guess is that the JavaScriptCore (WebKit's main JavaScript engine) parser needs to be changed. If so, you should probably file a bug at webkit.org. J On Mon, Dec 6, 2010 at 2:27 AM, Charles Pritchard ch...@jumis.com wrote: I just noticed that the cursor continue method in IndexedDB runs afoul of the Safari js parser, with continue being a reserved word. Was there any discussion on this issue? Should there be? Should I not worry about it, and use cursor['continue'] instead of cursor.continue() ? -Charles
Re: Structured clone in WebStorage
I recall talking to hixie about this at some point, and I recall that at that point localstorage was explicitly prevented from Blobs, although I can't see any sign of that rule anymore :-/ --Oliver On Dec 3, 2010, at 10:41 AM, Darin Fisher wrote: Have you guys considered what happens when a Blob is present? I'm very concerned about that case since WebStorage is a synchronous API. If storing a Blob in LocalStorage involves synchronous disk IO, then I'm pretty sure it is something I would object to implementing. I don't think there is a hand-wavy answer about performing a file copy asynchronously in the background. What if the file copy fails? -Darin On Thu, Dec 2, 2010 at 1:45 PM, Anne van Kesteren ann...@opera.com wrote: On Thu, 02 Dec 2010 21:51:29 +0100, Maciej Stachowiak m...@apple.com wrote: We think this feature would be straightforward to implement in Safari/WebKit, and we think it is a useful feature. We would like to implement it at some point. I can't give a specific timeline. I am not sure if it is straightforward to implement in Opera, but this applies to us as well. -- Anne van Kesteren http://annevankesteren.nl/
Re: DOM collections index out of bounds and JavaScript.
On Oct 18, 2010, at 6:11 PM, Cameron McCormack wrote: Erik Arvidsson: The problem is that trying to get a non existing property in JS should return undefined. Not null and not an empty string. I understand that the spec used null since Java does not have undefined. Since we are trying to realign these specs with the web it would make sense to try to make them fit better with JavaScript and mandate that the JS bindings for collections should return undefined for getting an item out of bounds. Does it particularly matter that collection.item(999) returns null while collection['999'] evaluates to undefined? To me, it makes sense enough. Functions and properties that returns Nodes, and which have no Node to return, return null. I think for consistency with all of these other funtions and properties, it is preferable to return null from collection.item(). That’s a much bigger (better) consistency to strive for than one between collection.item(999) and collection['999'], IMO. There's no difference between collection[999] and collection['999'] as an implementation has to check to see if a string can be converted to an integer (just as it does with array), otherwise for(in) enumeration would not work. Also in ecmascript logically all properties are string names it's only for reasons of performance that implementations distinguish integer vs. string property names internally. --Oliver -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] ArrayBuffer and ByteArray questions
On Sep 8, 2010, at 11:13 AM, Chris Marrin wrote: Web Sockets is certainly another candidate, but I meant Web Workers. There have been informal discussions on using ArrayBuffers as a way to safely share binary data between threads. I don't believe anything has been formalized here. You can't share data between workers. There is no (and there cannot be) any shared state between multiple threads of JS execution.
Re: [webidl] DOMString
Conceivably the language could be a relatively simple and broad statement along the lines of: Any type conversions needed for a language binding should occur before an API function is called, if a type conversion fails for any reason the call should be aborted However this doesn't address the issue of callbacks that throw exceptions, or returns incorrect types leading to an exception on type conversion, etc, etc --Oliver On Apr 21, 2009, at 11:46 PM, Cameron McCormack wrote: Hi Garrett. Cameron McCormack: We could certainly add similar language for the Java language binding section too, though I think there’s less scope for those conversions to throw exceptions (maybe ones like OutOfMemoryException). Garrett Smith: I'm not sure, but I think you might have meant OutOfMemoryError. Yep that’s what I meant. All Errors are unchecked in Java. Indeed. Java also has unchecked exceptions, though unlike Errors there are exceptions that are checked at compile-time (checked exceptions). All of the dom exceptions are runtime exceptions. (TYPE_MISMATCH_ERR, for example) Yeah, I’ve made those exceptions extend RuntimeException. Which languages don't throw unchecked exceptions? C, for example, which doesn’t have exceptions at all. Until (unless) somebody writes up a Web IDL language binding for Objective-C, the best you can hope for is for Obj-C implementations to do something “sensible”. Like throw a runtime error? Perhaps; I don’t know Obj-C so I couldn’t say. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [webidl] DOMString
On Apr 21, 2009, at 1:38 AM, Anne van Kesteren wrote:
If something takes a DOMString as value is it clearly defined what
happens if the toString algorithm throws or returns a non-DOMString?
I haven't been able to find descriptions for that in the Web IDL
specification. E.g.
obj = { toString:function() { throw(haha) } }
obj2 = { toString:function() { return 1 } }
obj3 = { toString:function() { return obj } }
The [[ToString]] algorithm is defined in ECMAScript (Section 9.8,
[1]), the specified behaviour would result in [[ToString]] on obj2
producing the string 1; [[ToString]] on obj3 will result in a
TypeError, as [[DefaultValue]] will produce a non-primitive type
(Section 9.1, [1])
I would assume that the exception will be propagated to the runtime,
but it should be stated.
--Oliver
[1] ECMA262-5 RC
http://www.ecma-international.org/publications/files/drafts/tc39-2009-025.pdf
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [webidl] DOMString
On Apr 21, 2009, at 6:08 PM, Cameron McCormack wrote: Anne van Kesteren: If something takes a DOMString as value is it clearly defined what happens if the toString algorithm throws or returns a non-DOMString? Oliver Hunt: I would assume that the exception will be propagated to the runtime, but it should be stated. Seems reasonable to state that. I’ve added a note to do that when I get some time to allocate to editing Web IDL again. I actually thought about this some more, and realised i'm not entirely sure this should be part of webidl as it seems a little too language specific. Eg. WebKit also provides an objective-c interface to the DOM to application developers, allowing them to interact with a webpage (or other content) through the DOM directly from their application code. Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: [webidl] DOMString
It’s only the ECMAScript language binding that uses the ES ToString etc. algorithms, so I think it would be fine to define in the ES language binding section that exceptions thrown when converting an IDL value to an ECMAScript value or vice versa will propagate to whatever invoked that conversion. Oh of course, completely forgot that there's actually a set of bindings sections :D Until (unless) somebody writes up a Web IDL language binding for Objective-C, the best you can hope for is for Obj-C implementations to do something “sensible”. Effectively this is what WebKit does to generate it's ES and Obj-C bindings. -- Cameron McCormack ≝ http://mcc.id.au/
Re: File Upload Status ?
Sorry, the and browser at the end was a typo. I meant to say,
in the
browser. The reason synchronous access to the disk is a bad idea
is that
if the operation takes too long, a big file, a slow network home
directory,
Then:
function readFile(file) {
// 1. Check the fileSize property.
if(file.fileSize 10) {
generateFileWarning(file);
return;
}
// 2. read file asynchronously.
setTimeout(readFile, 1);
}
seems to completey address the problems you mentioned in only a few
lines of code.
Alas this does not resolve the problem as you are making the implicit
assumption that because a 100k file access may be fine on your local
system, or even on a network drive on your local network it may not be
for someone using a network drive over a the net or on an otherwise
slow connection (this isn't necessarily an uncommon scenario, a person
using a vpn on a 56k modem could hit this or a person with a poor wifi
connection, etc). The file limit being 100k is a magic number that
could be replaced by any arbitrary value, but the simplest way to
break any size assumption is to consider what would happen if the file
you were attempting to load were on a network drive from a server that
just fell over.
In general APIs that require the developer to make this sort of
decision are poor as they tend to result in code that always uses the
synchronous API (because it's easy) because it works fine on the
developers system, even though it may not be even remotely useful for
many people. The other scenario is that the developer does do some
testing, but doesn't test every possible configuration, once again
resulting in some people being unable to use the site/application.
The other problem is that setTimeout does not result in async
javascript execution it merely delays the synchronous execution of a
script. In your example you are returning from readFile (to prevent
your code from blocking the UI) and then the moment the timer is
triggered a synchronous read of a definitely large file will occur,
resulting in the UI being blocked.
The only way to prevent such UI blocking is to have an async api
regardless as to whether you have a synchronous one, meaning that the
synchronous api will only exist to either increase complexity (as
developers will need to implement logic to fallback to, and implement,
the async I/O in addition to the synchronous I/O logic as your above
example would need to), or to produce sites that fail to account for
non-fast I/O (which thus destroy the end user experience).
--Oliver
