Re: [chromium-html5] LocalStorage inside Worker
So long as you only allow asynchronous access the implementation can ensure that a worker and the main thread doesn't have access to the storage at the same time. Then it is safe to allow everyone to modify the storage area. / Jonas This is true, serialising access would have the same semantics as STM. Infact you could consider STM to be a performance enhancement to sequential access by optimistically allowing concurrent modifications and only doing something special if there is a collision (a read from a location written by another thread during the transaction). In which case STM works like a database and rolls back the transaction. It is really putting a thread local log between the user and the storage. The main storage is then only locked during the log commit, reducing resource contention. A rollback is simply discarding the log. But this would behave identically (apart from the extra features in STM like guards and retry) to serialisation of requests. A simple (non STM) implementation would be to have a single thread associated with the localStorage and require all accesses to be executed by that thread (in callbacks). You could use the main UI thread, but it would make worker threads wait for storage access during DOM processing in callbacks etc... Cheers, Keean.
Re: [chromium-html5] LocalStorage inside Worker
On Fri, Jan 7, 2011 at 4:58 PM, Glenn Maynard gl...@zewt.org wrote:
A solution that makes localStorage read-only in workers is no solution.
If the current implementation of localStorage is broken by opening two
tabs, then why not allow workers to access the localStorage already?
As you have mentioned, it is no different than opening several more
tabs. So, assuming the localStorage is consistent even with multiple
tabs open, the remaining problem is dealing with the workers' access.
I fail to see why making a read-only localStorage in workers is a no
solution?
Thanks to Keean's pointer, I dug up a short but really helpful STM talk:
http://blip.tv/file/get/OSCON-OSCON2007SimonPeytonJones914.mov
Go back to the multiple tabs problem: if we opened 10 tabs, then the
interleaving JS (mentioned by Boris) may degrade the performance by
10 times. In this case, perhaps we need STM (those who use STM will
gain performance, those who don't will fallback to interleaving JS)?
On Fri, Jan 7, 2011 at 5:33 PM, Keean Schupke ke...@fry-it.com wrote:
- It solves the efficiency problem
From the video, I see that while optimistic is good for performance,
in the same way it's bad for performance since it have to keep a log
(for rollback). I believe Jonas' getBetterStorage doesn't need to
maintain a log as it is assumed that it never have to
retry/rollback/fail, but it is executed single-threadedly. Application
specific benchmark is needed... but I believe both will be efficient
enough.
It also has the following advantages (quoted from the tutorial I posted):
- No race conditions due to forgotten locks
Race conditions still happen if you (jarringly) forgot to wrap your
shared object inside atomic block :P. So, maybe it's a good idea to
only allow localStorage to be accessed inside an atomic block (even in
workers)?
On Fri, Jan 7, 2011 at 5:39 PM, Keean Schupke ke...@fry-it.com wrote:
Ok. But what i'm trying to say is, forcing the localStorage to use
atomic block is a bad idea in the main page thread since a
transaction in the main page thread can span very long time perhaps
committed by a click event.
How is this any different from having a big loop an any callback:
var onclick = fuction() {
for (i = 0; i 10; i++) {
// do some work
}
}
I've just made the page non-responsive...
Also notice:
atomic(function(state) {...})
The commit happens automatically when the callback function returns, so a
split transaction (the commit in a callback) is impossible with this
formulation. Just think about the lexical-scoping.
An example of a long transaction that committed in a callback is:
you are committing based on the return value of an AJAX call... and to
make that AJAX call, you require to be inside atomic block while
reading some shared value... I know it's a bad example, but it's one
of the idea of the long transaction I mentioned. So I guess atomic
doesn't span to a very long transaction (it does not necessarily
need to make the browser unresponsive).
But I agree, for short transactions, it looks simple and perfect.
In the video, the proposed atomic is blocking. So, perhaps the
Javascript API needs to supply a callback (for non-blocking) to be
called after the atomic routine is finished?
Felix Halim
Re: [chromium-html5] LocalStorage inside Worker
Race conditions still happen if you (jarringly) forgot to wrap your
shared object inside atomic block :P. So, maybe it's a good idea to
only allow localStorage to be accessed inside an atomic block (even in
workers)?
Yes, that was in my original suggestion.
atomic(function(shared) {...});
The callback scoped variable shared is the only way to access the shared
namespace.
Cheers,
Keean.
Re: clipboard events
Thanks for working on this! On Wed, Jan 5, 2011 at 2:41 PM, Ryosuke Niwa rn...@webkit.org wrote: If the cursor is in an editable element, the default action is to insert clipboard data in the most suitable format supported for the given context. In an editable context, the paste event's target property refers to the element that contains the start of the selection. In a non-editable document, the event is targeted at a node focused by clicking or by an interactive cursor. If the node that has focus is not a text node, the event is targeted at the BODY element. I'm not sure if it makes sense for the element to be the start of selection. Why not just pass the root editable element? The website already have access to the selection so it can get start/end of selection. Mentioning of clicking or cursor is unnecessary. One can use keyboard to move focus / selection and copy / paste should still work. I'm not sure why we're special-casing text node / non-text node. Is there some reason to this? (i.e. compatibility with Internet Explorer?) Ditto on all points. Also, why does this clause not apply to the cut/copy events as well? What does start mean here? Start in document order e.g. as opposed to the anchor/base of the selection? This .types spec is slightly different from the HTML5 DnD .types - consistent enough to make sense to authors and implementers? What's the benefit of being different? In general, the closer we can be to HTML5 DnD, the easier it will be for everyone. Implementations are encouraged to also support text/html for dealing with HTML-formatted data. In an ideal world, implementations would support any string type. This would allow for creating custom clipboard formats as well as common mime types (e.g. image types). Do most operating systems support setting generic string types on the clipboard? Ojan
Re: clipboard events spec and HTML5 spec - divide and conquer, but where?
On Fri, 7 Jan 2011, Hallvord R. M. Steen wrote: On Fri, 07 Jan 2011 04:31:01 +0900, Ian Hickson i...@hixie.ch wrote: On Thu, 6 Jan 2011, Hallvord R. M. Steen wrote: I've done some work on a spec for clipboard events, initially just to make up my mind about what Opera needs to implement, but as it might be a useful thing in general I've volunteered to edit it as a WebApps WG delivery. It will be a fairly small spec, only handling clipboard events. Is it intended to also cover cut, copy and paste? Sorry, I don't understand the question. Well, for example, the 'cut' operation involves removing or mutating DOM nodes (for contentEditable) or editing the control value (for input) or raw value (for textarea), and modifying the selection accordingly. Similarly, 'paste', e.g. for input, involves changing the input value, firing 'input' events, modifying the selection, etc. The current spec draft seems very vague about when the events fire and what their default actions are, but I can't tell if that's intentional or not. No vagueness is intended. Could you give me two examples of things that needs to be more specific, one regarding timing and one regarding default action? Sure. For example, when should the paste event fire relative to when keydown/keyup events fire? When should the paste event fire relative to when the 'input' event fires? Should it fire asynchronously as a separate task; should it fire as part of the default action of the keypress event synchronously? Where do these events fire relative to mutation events, for contentEditable? What should the default action of 'paste' be, in terms of DOM mutations when the cursor is in a contentEditable section? How should DataTransfer be set up when the data comes from a non-Web source? Another example, more editorial, is that the spec currently doesn't have a conformance section and doesn't define how to determine what the normative conformance requirements are. Assuming RFC2119 semantics, the spec is lacking detail. For example, nothing normatively says whether the events bubble or not, it's just left up to the reader to assume that the table implies that it does. There's also no normative requirement linking the description of what the target is to the actual firing of the event. For some background, see: http://ln.hixie.ch/?start=1140242962count=1 When the spec says A must do B. B's C is D., the second sentence is not normative, it's just descriptive -- describing what another part of the specification presumably requires. I assume you intend something more like A must do B, with B set up as follows: B's C must be D. or some such. Now, this needs a bit of syncing with HTML5 because right now that spec defines a ClipboardEvent interface that contains some of the stuff in HTML5's DataTransfer interface. To avoid this overlap I guess there are two ways forward, either I remove those bits from the clipboard events spec and reference HTML5, or you remove them from HTML5 and say that DataTransfer extends ClipboardEvent. I'm happy either way (though if I'm going to reference DataTransfer I'll call out explicitly what methods are required for clipboard events and omit the DnD specific stuff). Which approach do you think would be better? What do browsers do? Do they use the same object, including the drag-and-drop specific attributes, or is it a different interface? In WebKit, event.clipboardData in copy/cut/paste events and event.dataTransfer in drag/drop events both implement a Clipboard interface, so the same attributes are available. In that case we should probably just use the same interface, and put copy/paste and drag/drop in the same spec. If they're in separate specs, it's probably simplest if the DataTransfer stuff is with the DND stuff, since that's the main driver for changes to the DataTransfer interface. I'm happy to work with you to make sure the DataTransfer spec still works for copy/paste. Conceptually, copy/paste and drag-and-drop can be viewed as the same thing (indeed, an older version of the HTML spec actually defined copy/paste in terms of DND), so this should be relatively simple. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Limited DOM in Web Workers
Hi, I have a proposal of sorts, regarding Workers. As we all know, there's no access to the DOM from within a Web Worker. While this is ideal for security purposes, I can't help but think a restricted subset of the available DOM manipulation methods would be incredibly useful. I'm not talking about allowing Worker's to manipulate the main DOM tree of the page, but rather, exposing DOMParser, and XMLHttpRequest.responseXML, and a few other objects to workers, to allow the manipulation of DOM trees which are never actually rendered to the page. This would allow developers to parse and manipulate XML in workers, freeing the main thread of a page to perform other tasks. A possible counter argument, may be Why not just use JSON instead?, and while I agree that JSON is the easiest method of serialising and parsing objects, sometimes developers must work with data from a source which only provides XML. An example of a use-case, I'd like to hack on the Strope.js XMPP implementation to allow it to run in a worker thread, currently this is impossible, without writing my own XML parser, which would undoubtedly be slower than the native DOMParser) Any thoughts? Regards, Jack Coulter
Re: [chromium-html5] LocalStorage inside Worker
On 1/6/2011 3:20 PM, Jonas Sicking wrote: On Thu, Jan 6, 2011 at 3:06 PM, Charles Pritchardch...@jumis.com wrote: Shouldn't sessionStorage be made accessible? I don't think localStorage should be (to web workers), but sessionStorage seems a reasonable request. Why wouldn't that have the same threading issues as I described? There a good reason for it to have those issues in sessionStorage. localStorage need not. At least when it comes to workers. They use synchronous interfaces in the File API, too. Would you rather File API be used to create locks? Keep in mind that sessionStorage is limited to 5 megs: these are reasonably small areas of memory, and they're not written to that often. On 1/6/2011 4:19 PM, Glenn Maynard wrote: On Thu, Jan 6, 2011 at 6:06 PM, Charles Pritchardch...@jumis.com wrote: Shouldn't sessionStorage be made accessible? I don't think localStorage should be (to web workers), but sessionStorage seems a reasonable request. Why? I've wanted to access localStorage from workers in the past, and if the details for accessing Storage objects are worked out at all, then exposing sessionStorage but not localStorage seems arbitrary and unnecessarily restrictive. It's not arbitrary: the names local and session convey some meaning. localStorage works well enough, out in the wild. sessionStorage is not in wide use. I don't think it's restrictive, it just creates a wider implementation divide between session and local. You can still use your main thread to loop through session storage and copy it into local storage.
Re: [chromium-html5] LocalStorage inside Worker
On Thu, Jan 6, 2011 at 6:06 PM, Charles Pritchardch...@jumis.com wrote: I don't think localStorage should be (to web workers), but sessionStorage seems a reasonable request. It's not arbitrary: the names local and session convey some meaning. localStorage works well enough, out in the wild. sessionStorage is not in wide use. I don't think it's restrictive, it just creates a wider implementation divide between session and local. What I meant was: you said that you don't think localStorage should be available to workers, but I don't understand why. Why should sessionStorage be available, but localStorage not? -- Glenn Maynard
Re: Limited DOM in Web Workers
On 1/7/11 2:29 PM, Jack Coulter wrote: I'm not talking about allowing Worker's to manipulate the main DOM tree of the page, but rather, exposing DOMParser, and XMLHttpRequest.responseXML, and a few other objects to workers, to allow the manipulation of DOM trees which are never actually rendered to the page. Whether they're rendered doesn't necessarily matter if the DOM implementation is not threadsafe (which it's not, in today's UAs). That said... This would allow developers to parse and manipulate XML in workers, freeing the main thread of a page to perform other tasks. ... An example of a use-case, I'd like to hack on the Strope.js XMPP implementation to allow it to run in a worker thread, currently this is impossible, without writing my own XML parser, which would undoubtedly be slower than the native DOMParser) If you think you could do this with your own XML parser, is there a reason you can't do it with e4x (I never thought I'd say that, but this seems like an actually good use case for something like e4x)? That should work fine in workers in Gecko-based browsers that support it, and doesn't drag in the entire DOM implementation. That leaves the problem of convincing developers of those ECMAScript implementations that don't support e4x to support it, of course; while things like http://code.google.com/p/v8/issues/detail?id=235#c42 don't necessarily fill me with hope in that regard it may still be simpler than convincing all browsers to rewrite their DOMs to be threadsafe in the way that would be needed to support exposing an actual DOM in workers. -Boris
