[whatwg] Worker feedback

On Fri, Apr 3, 2009 at 9:00 AM, Jeremy Orlow <jorlow at google.com> wrote:

> The problem is escalating the lock.  If your script does a read and then a
> write, and you do this in 2 workers/windows/etc you can get a deadlock
> unless you have the ability to roll back one of the two scripts to before
> the read which took a shared lock.  If both scripts have an 'alert("hi!");'
> then you're totally screwed, though.
>

Double oops! Yes.

On Wed, Apr 1, 2009 at 3:02 PM, Robert O'Callahan <robert at ocallahan.org>
>  wrote:
>
>> getItem stability is helpful for read-only scripts but no help for
>> read-write scripts. For example, outside a transaction, two scripts doing
>> putItem('x', getItem('x') + 1) can race and lose an increment.
>>
>
> Totally agree that it doesn't quite work yet.
>
> But what if setItem were to watch for unserializable behavior and throw a
> transactCallback when it happens?  This solves the silent data corruption
> problem, though reproducing the circumstances that'd cause this are
> obviously racy.  Of course, reproducing the deadlocks or very slow script
> execution behavior is also racy.
>

You mean throw an exception when it happens? Yeah, that doesn't really help,
you just replace one kind of random failure with another. A half-completed
read-write script is very likely to have corrupted data.


>
>> Addressing the larger context ... More than anything else, I'm channeling
>> my experiences at IBM Research writing race detection tools for Java
>> programs ( http://portal.acm.org/citation.cfm?id=781528 and others), and
>> what I learned there about programmers with a range of skill levels
>> grappling with shared memory (or in our case, shared storage) concurrency. I
>> passionately, violently believe that Web programmers cannot and should not
>> have to deal with it. It's simply a matter of implementing what programmers
>> expect: that by default, a chunk of sequential code will do what it says
>> without (occasional, random) interference from outside.
>>
>
> I definitely see pro's and cons to providing a single threaded version of
> the world to all developers (both advanced and beginner), but this really
> isn't what we should be debating right now.
>

Why not? I know of no better forum for debating the semantics of the Web
platform, and it's clearly a matter of some urgency.

What we should be debating is whether advanced, cross-event-loop APIs should
> be kept simple enough that any beginner web developer can use it (at the
> expense of performance and simplicity within the browser) or if we should be
> finding a compromise that can be kept fast, simple (causing less bugs!), and
> somewhat harder to program for.
>
> If someone wants to cross the event loop (except in the document.cookie
> case, which is a pretty special one), they should have to deal with more
> complexity in some form.  Personally, I'd like to see a solution that does
> not involve locks of any sort (software transactional memory?).
>

I agree it would make sense for new APIs to impose much greater constraints
on consumers, such as requiring them to factor code into transactions,
declare up-front the entire scope of resources that will be accessed, and
enforce those restrictions, preferably syntactically --- Jonas' asynchronous
multi-resource-acquisition callback, for example. That is entirely
consistent with what I said above; I'm not saying all concurrency
abstractions are intractable. But the "abstraction" which takes sequential
code and adds races on shared storage everywhere certainly is.

Unfortunately we have to deal with cookies and localStorage, where the API
is already set.


>
>> I realize that this creates major implementation difficulties for parallel
>> browsers, which I believe will be all browsers. "Evil', "troubling" and
>> "onerous" are perhaps understatements... But it will be far better in the
>> long run to put those burdens on browser developers than to kick them
>> upstairs to Web developers. If it turns out that there is a compelling
>> performance boost that can *only* be achieved by relaxing serializability,
>> then I could be convinced ... but we are very far from proving that.
>>
>
> Like I said, a LOT of research has been done on concurrency.  Basically, if
> you're not really careful about how you construct your language and the
> abstractions you have for concurrency, you can really easily back yourself
> into a corner that you semantically can't get out of (no matter how good of
> a programmer you are).
>

I know this, but I'm not sure exactly what point you're trying to make.

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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090403/86fa1d9e/attachment.htm>

Received on Thursday, 2 April 2009 18:37:49 UTC