Build without SharedArrayBuffer

[jason-variadiclabs]

Is it possible to compile webR without using workers? I'm interested in running some R code natively in the browser, but the requirement is that it has to run without SharedArrayBuffers (have to be able to load locally from file:// which is currently not supported yet in Chrome/FF).

If it's a matter of performance (takes a while to download the WASM binary, load dependencies, etc.) that's not an issue, just wondering if it's possible. It does seem the emscripten flags use fetch, is SharedArrayBuffers required due to using fetch's async mode?

[lionel-]

We've decided to make workers a requirement for webR because it simplifies the implementation and prevents R from blocking the main browser thread while it is busy, which would hinder user experience.

It is in principle possible to implement the communication channel between the workers without SharedArrayBuffer (using a service worker instead), but we don't have any plans to add this at the moment.

[SugarRayLua]

@jason-variadiclabs: the older webR version that doesn't use workers seems to still be up in case you wanted to check that out at:
https://www.mas.ncl.ac.uk/~ngs54/webR/

I'm still running that older version locally on my mobile device with a local server on that device (iPad)

[georgestagg]

Do note that I no longer work for Newcastle University, where that older build is hosted. As such, I can not guarantee how long it will remain up, and it should be considered unsupported.

[SugarRayLua]

Duly noted and thanks for clarifying.

[jason-variadiclabs]

thanks @lionel- @SugarRayLua and @georgestagg . Would the older webR source be available somewhere, maybe in an older commit/branch of this repo? I may end up forking the current repo and build a barebones solution without a REPL terminal, since all I need is to be able to take R code and display the output in an HTML canvas.

[lionel-]

Note that this is not about REPL terminals but about the browser thread. Without a worker, the whole tab will freeze while R is computing something.

[jason-variadiclabs]

Understood, that should be fine. The use case involves a script that is most likely generating a static image, so it's okay if the browser thread is consumed rendering it (won't be sending interrupt signals or anything like that). Animated plots in theory should render properly too since it's using the browser thread, just interactive stuff won't work without modifications.

[georgestagg]

In theory the older experimental versions of webR without use of Workers and SharedArrayBuffer are available in the git repo history, but I don't recommend using them going forward. We are aware of serious stability issues in those older versions, on top of the browser hanging during computation issue.

I understand that the SharedArrayBuffer requirement can be a problem, particularly when there is no server (e.g. serving from file://). For the moment, you might be able to get away with spinning up a local server that sets the required security headers for you. An example Python script that does this can be found at src/webR/serve.py. When the docs are published a further explanation of that will be included there.

For the future, if it becomes a serious problem for users I will look into the possibility of running webR in a way that does not setup its own Workers and communication channel, and so could be used when SharedArrayBuffer is unavailable. I think it should be possible but there will be serious drawbacks in such a case: the normal R REPL will be unable to be interactive, long computation will lock up the browser tab, downloading files with R will not be possible, possibly further drawbacks.

For the above reasons, I'll consider the workerless investigation a low priority. Probably at least until after the first versioned release is finalised and we have some more feedback.

[georgestagg]

See the webR docs at https://docs.r-wasm.org/webr/latest/communication.html for details on how it is now possible to use webR without SharedArrayBuffer by using the PostMessage communication channel, albeit with some drawbacks.

In this mode, a worker thread is still used, for all the reasons that Lionel outlined earlier in this thread.