Re: Sync API for workers

Le 04/09/2012 20:47, Glenn Maynard a écrit :
> On Tue, Sep 4, 2012 at 12:49 PM, David Bruant <bruant.d@gmail.com
> <mailto:bruant.d@gmail.com>> wrote:
>
>     I'm sorry, but I have to disagree. Have you ever used promises in
>     a large-scale project?
>     I've been amazed to discover that promise-based API are
>     ridiculously much easier to refactor than callback-based API.
>     Obviously, refactoring necessitates well-scoped state. I can't
>     show the commit I have in mind, because it's in closed-source
>     software, but really, a promise-based API isn't less
>     understandable and less well-scoped. That statement is at the
>     opposite direction of my experience these last 8 months.
>
>
> You have to choose between scoping state to a class (poor scoping) or
> in closures (hard to debug) instead of using locals in a call stack
> (tightly scoped and easy to debug); the overall current state of
> execution is much harder to see compared to a stack trace; the basic
> idea of stepping through code in a debugger scarcely translates at all.
Tooling isn't perfect for async debugging. It's being worked on. Yet it
hasn't prevented web devs from buiding (and debugging) event-based code.

As someone else said in another message, async isn't going away. There
won't be new blocking API for the main thread, so all the costs of
learning async programming will have to be paid. Debugging included.
I'm less and less convinced there is really something substancial to win
from the JS developer perspective.

For small scripts, it will be possible to use blocking APIs, but the
cost of async in small scripts is bearable. For big scripts, blocking
APIs induce a performance cost that soon makes people move to async.

>
>     I understand and agree, but you're not addressing the problem of
>     the resource waste I've mentionned above.
>
>
> I don't feel like I need to, because I expect this question was
> explored before workers were introduced in the first place.
It likely hasn't because workers do not have access to blocking APIs
except sync xhr. Are there examples in the wild of people creating new
workers when one is doing a sync xhr or do people just turn their code
into async when performance becomes an issue?
If the question has been explored before, can anyone point to the
answer? Otherwise, the debate won't move forward on that point.

> You apparently want to argue against *all* sync APIs, but you should
> do that separately, rather than singling out one sync API at random.
As I said in a previous message, I'm arguing against the waste of
resources due to blocking APIs. If a sync API makes an actual use of the
worker and CPU, that's excellent. If it's blocking on IO, it's wasting
resources that could be doing other computations.

David