SharedArrayBuffer and Workers implementation with V8

[nextfool]

Hi community,

I have some questions regarding implementing the "SharedArrayBuffer" and "Worker" with clearscript.
As we know that, the "SharedArrayBuffer" is among the "javascript standard built-in objects" along with "Atomics api"

But "Web worker" is part of the "web api" which is implemented in the "browser" side, so there is NO native V8 support of it.

Thanks to @ClearScriptLib , they have this nice worker implementation example available.

But now the dilemma is that, the SharedArrayBuffer and Workers usually work together:

var worker = new Worker('worker.js'),
var buffer = new SharedArrayBuffer(1);
worker.postMessage(buffer );

onmessage = (buffer)=>{
var arr = new Int8Array(buffer);
}

To my understanding, the above code, will run in two different "contexts", while the worker runs at the "c# side", the "SharedArrayBuffer" runs at the "native v8 side". To handle the posted message at the "c# side", I need to get the reference of the "SharedArrayBuffer" which is basically a pointer to a physical memory address (point me out if I was wrong)? Well the problem is, I just can not get the "pointer" value as it is hidden deep in the private field inside some v8 native objects.

So now I guess I have two options:

1. If there is any way which allows me to get the "value of the pointer", so I can pass this "pointer" to the code in a worker, so the javascript code can truly "share memory" within V8's native heep.

2. If No.1 is not feasible, I am thinking of implementing the "SharedArrayBuffer“ as well as the "Atomics" apis (with c# Interlocked apis") at the "c# side", and "override" the default built-in apis from V8. In this case, performance maybe an issue, as each "atomics" operation will now happen on CLR's "managed heap" (again, please point me out if I am wrong)?

So please help me in every ways, any comment/advice/solution is very much appreciated!

Thank you in advance.

[ClearScriptLib]

Hi @nextfool,

As you point out, SharedArrayBuffer is a standard JavaScript built-in, and V8 has supported it for a while now.

However, ClearScript currently provides no special treatment for SharedArrayBuffer objects. That is, a SharedArrayBuffer is a script object like any other. You can pass it to the host, invoke its members from .NET, etc. The host can pass it to another script engine, but as with any foreign script object, the result is a doubly-marshaled reference – a proxy to a proxy – that goes through the host for all member access.

Exposing foreign script objects isn't something we recommend. In addition to overhead, deadlock becomes a point of concern, as each script engine has its own internal mutex. Furthermore, proxying a SharedArrayBuffer in this manner is particularly pointless, as you couldn't use the resulting reference to construct a TypedArray or DataView.

If there is any way which allows me to get the "value of the pointer", so I can pass this "pointer" to the code in a worker

No. A SharedArrayBuffer's backing store isn't accessible from JavaScript or C#, nor is there any way to construct a new SharedArrayBuffer on top of an existing backing store. That can only be done via V8's native C++ embedding API.

To support your scenario, ClearScript needs an enhancement whereby exposing a foreign SharedArrayBuffer has the expected behavior – both engines get local script objects that share a backing store. This should also work for shared TypedArray and DataView objects, as that would agree with Chromium behavior.

Thank you very much for making us aware of this!

UPDATE: We've created Issue #317 to track the implementation of this enhancement.