Hi Saúl,
the Worker specs state, that messages passed thru different contexts
must be 'clonable', therefore somehow be serializable..
For a 'low footprint' environment the serialize/post/deserialize cycle
might be a bit to much an effort for simple message passing though, but
you wouldnt have to interfere with the gc() stuff of the runtimes
(especially as the implementation details may change in time).
this might be of interest:
https://developer.mozilla.org/en-US/docs/Web/API/Worker/postMessage
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm
greets
maG
On 13.08.19 19:26, Saúl Ibarra Corretgé wrote:
On 13/08/2019 18:05, Charlie Gordon wrote:
On 13 Aug 2019, at 17:53, Saúl Ibarra Corretgé <s@xxxxxxxxxx> wroteI should have clarified :-) I plan on passing the pointer to the memory
On 13/08/2019 17:24, Mario Gliewe wrote:Interesting work around… but passing the refcount from one runtime to
hi,I've been wondering about tthis myself. Since the runtime and contexts
are there any predictions as much the js runtime/context is threadsafe?
would it be feasible to create a Worker by just instantiate a new
context in a new thread and let them interact via pipes (or whatever ipc)?
greets
maG
are not thread-safe, my current plan is to use a pipe to send messages
across threads (each worker would run a new runtime on a thread).
The ticky part will be to send SharedBuffer instances across. My plan is
to write the pointer address on the pipe and up the refcount on the main
process, then "rebuild" the array in the worker based off the given pointer.
another seems risky:
it will work only as long as the object is still referenced by all runtimes.
in the SharedArrayBuffer. The way to ensure it will. remain valid would
be to DupValue the JSObject every time I send it across, and FreeValue
it every time a worker dies. There is rist, of course, but I think it
might work...
A builtin scheme seems more palatable.Can you elaborate? I'd be more than happy to use a better solution!
Cheers,
