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....@4d.com Web : www.4D.com ________________________________________
