RE : Sync IO APIs in Shared Workers

Hi everyone,

The original email from Jonas has been posted a while ago, here are a few comments about it.
Sorry for being late.

IMHO, we should make sync APIs available in both dedicated and shared workers.
In order of importance:

1) Sync APIs are inherently easier to use than async ones, and they are much
less error prone. JS developers are not C++ developers. Whenever possible, it's
just better to make things more simpler and convenient.

2) Sync APIs do the job. We are talking about web-apps, not heavy load servers.
High performance applications will use async APIs anyway. I'd rather think there
are a lot of use cases where the dedicated or shared worker would do a lot of small
and short duration work, suitable for sync coding. Why force the complication of async
on developers ? If easy things can be done easily, then let it be.

3) It does no harm.

Web workers execute in separate threads so the main thread isn't impacted (non
responsive). Of course, it'll have to wait for answers from the workers. But
that's a design problem: Just add timeouts in the main thread. If no answer
from workers after a certain amount of time, then take appropriate actions
(advise user for instance).

As for shared workers, this is also a design problem: If one resource is
supposed to be shared by several, then don't allow one to keep it for too long
(long request). Instead, use dedicated workers for that purpose. By not
allowing sync APIs in shared workers, you're indeed preventing bad practice,
but you're also preventing good legitimate uses. I would prefer that power users
are allowed to make full use of available APIs.

The most interesting point in [1], is that to make workers responsive (able
to interrupt work for instance) in non trivial applications, you have to chunk
the work in slices and do async programming anyway. Hence the conclusion that
because you end up async, there is no point of having sync APIs. I disagree. As
stated before, there are cases where sync APIs do the job adequately, and in my
opinion, I believe they may not be the less numerous use cases. Also, sync and
async can well be mixed. It can sometimes be more practical and elegant to have
async control (messaging and work chunk management), while the actual work is done
using sync APIs.

Now regarding proposed work-arounds. IMHO, I'd rather think the current facilities are
adequate enough. Here are a few comments:

1) An object in parent allowing to abort current operation in a worker ?

That's basically some sort of EINT and this will somewhat defeat the purpose of ease
of use of sync APIs. For each API, you will have to specify what methods can be
interrupted and what happen: atomic operation (all or nothing) ? partial work possible ?
That would not complicate things much for simpler applications as they will probably never
interrupt a worker. Hence they won't have to handle interruptions.

However, the problem is that it just "changes" the JavaScript language programming "model".
In JS, things are either sync (the usual imperative programming language way) or event based
(async) using callbacks. This will add on top it the notion of interrupt ?

IMHO, this solution is acceptable but I personnaly won't recommend it. Main reason is that
it adds "interrupts" on top of "callbacks", this makes things more complicated. I view that
rather as a shortcut than a solid solution (use work chunking).

2) Message polling ?

IMHO, this is like opening a pandora box. In the end, some developers won't resist and will
do active waiting.

[1] http://infrequently.org/2013/05/the-case-against-synchronous-worker-apis-2/





Ke-Fong Lin
Développeur Senior

4D SAS
60, rue d'Alsace
92110 Clichy
France

Standard :
Email :    Ke-Fong.Lin@4d.com
Web :      www.4D.com


________________________________________

Received on Wednesday, 4 December 2013 10:54:30 UTC