Why does Node.js not provide something like SharedObjectBuffers out of the box?

[hjerabek]

First, I want to thank @Bnaya very much for creating and sharing this great library, and for putting in the effort to maintain it. Keep up the great work!

My main question is why projects like Node.js do not provide a solution like this out of the box. IMO, any application that requires sharing large objects between worker threads benefits from not having to permanently serialize and deserialize the objects. Yet, this objectbuffer is the only solution I could find that comes close to what I would consider a proper SharedObjectBuffer implementation. Can anybody give me a reason for this? A frequent "excuse" to not implement SharedObjectBuffers are potential race conditions, but, as this project shows, this can be solved with locks...

[Bnaya]

Thanks for the warm words @hjerabek!
If you are going to use the library, I would love to hear user perspective feedback.

Regarding your question, I can't speak for Node.js or browser vendors, but i will share my thoughts

Node.js maintainers and contributes are open source people and enthusiastic like us.
It means that it's not that no one want to have this kind of functionality, but someone need to build it, polish it and bring it via the node steering committee, and apply the feedback given etc.
To bring any functionality into standard library or a language or framework, it should not contain any foot guns and need to be optimised for most use-cases.
Giving users magic tool like objectbuffer that they can easily data-race themselves or get a deadlock is something very tricky.

The second part is, while I think objectbuffer is cool and works when the user knows the domain,
A lot of the mechanisms are naive, require a lot of user intervene (setting heap size, manual object dispose) and there's inherent overhead compared to plain JS, so I really can't "sell" it was silver bullet.

I even not sure how the final public API should look like 😅

That said, I'm still improving it, next phase is probably going to be a more minimal, inline-able allocator that i hope will allow me to also improve other things

[addaleax]

Just weighing in as somebody who did a lot of the Worker implementation in Node.js core – we’re really careful about bringing in features that can also be implemented in JS on top of the Node.js core APIs. Usually, packages published to npm have a bunch of advantages compared to built-in features:

• They can be maintained separately
• They can be updated separately
• They can be exchanged for other modules with similar functionality, or forked more easily

That being said, I think for this kind of feature, one could aim for a long-term solution in which the language itself would specify how to share objects between threads, on-heap, with no serialization or deserialization at all (not even reading/writing strings from buffers or similar conversions). That would be a language-level concern, and not one for Node.js, though.

[hjerabek]

Thank you for your replies.

@Bnaya:
I can imagine that it's difficult to take care of all the concurrency pitfalls, like races and deadlocks, and to find a solution that is optimized for most use-cases. That's why people like me, who do not have the proper expertise to tackle such issues, are very grateful that developers like you publicly share their solutions. I will start using objectbuffer more frequently and will provide feedback about my experiences here.

@addaleax:
I do agree with your general notion to be careful about adding new features to the Node.js core that can be implemented via JS (on-top). That "mantra" among the Node.js developer team is probably the reason why the Node.js runtime is still so slim and resource-efficient after all those years of development. Setting aside the fact that a low-level implementation in the core would most likely be much more performant than a respective JS solution, I was just amazed that there seems to be so little demand for a SharedObjectBuffer-like implementation within the Node.js community that there are practically no solutions out there (actually @Bnaya's objectbuffer is the only one I found so far that does not require predefining object schemes). PS: Thanks for giving us worker threads - they are great :)

[Bnaya]

Worth noting:
There's a stage 1 proposal to add fixed-shape objects to js, that will also be shareable across realms,
possible in a thread-safe manner
https://github.com/syg/proposal-structs