I really like the idea of some generic yield, though I wonder if there's
some reason it hasn't been added earlier.  People have been using the
setTimeout(..., 0) trick for a while to get around slow script warnings (and
general unresponsiveness)...so surely something like this must have come up
before?  If so, what were the drawbacks?
On Mon, Mar 23, 2009 at 2:24 PM, Robert O'Callahan <rob...@ocallahan.org>wrote:

> On Tue, Mar 24, 2009 at 7:41 AM, Jeremy Orlow <jor...@google.com> wrote:
>
>> One thing that hasn't been considered yet is some sort of optional hint to
>> say "I'm done" in terms of accessing localStorage.  Maybe call it
>> localStorage.checkpoint() or localStroage.commit()?
>>
>> As far as the browser implemenation is concerned, a call to this function
>> would be the same as the script ending.  The great thing about this is that
>> if a developer found one problem location in their code, they could add
>> it--but it'd be completely optional.
>>
>
> You mean if they find a performance problem due to overlarge lock scope?
>
> That's not a terrible idea. It certainly makes far more sense to be safe by
> default and add constructs and code to gain a bit more parallelism, than to
> be unsafe and parallel by default and have to add constructs and code to get
> safety.
>
> I'm not sure what the semantics of a standalone "commit()" would be,
> though. I think a better construct might be some sort of "yield" which
> explicitly returns to a (nested) browser event loop and basically acts as a
> script completion point. Even browsers that only use a single thread can run
> the event loop there so that testing in those browsers will reveal bugs.
>
>
> Rob
> --
> "He was pierced for our transgressions, he was crushed for our iniquities;
> the punishment that brought us peace was upon him, and by his wounds we are
> healed. We all, like sheep, have gone astray, each of us has turned to his
> own way; and the LORD has laid on him the iniquity of us all." [Isaiah
> 53:5-6]
>

Reply via email to