Add SharedArrayBuffer support

[jdesboeufs]

Hi @mourner,

I hope you, your family and friends are still safe.

This PR adds support for SharedArrayBuffer which is a fully compatible alternative to ArrayBuffer.

Firstly it allows a SharedArrayBuffer to be given to Flatbush.from(). Up to now it throws Data must be an instance of ArrayBuffer.

Secondly it adds a new optional parameter to the constructor: useSharedArrayWorker.

Before to go further, I need to know what do you think of this.

Why use a SharedArrayBuffer? You can share the data between multiple workers (Worker, SharedWorker, ServiceWorker and lower memory footprint.
In my use case, the R-tree is big! (~2.5GB).

Jerome

[mourner]

Overall this definitely makes sense, thanks for the PR! Left a few nits inline. Also, I'm wondering if this could be covered by some kind of tests, even if SharedArrayBuffer is mocked?

[mourner]

Two issues here, if I'm following this right:

• In case SharedArrayBuffer isn't available, just referencing it will throw an error, so this won't work as a check. We need to use typeof.
• If we fix the reference, the whole condition will still evaluate to false in case of a wrong data type, so the error won't be thrown.

So this would need to look something like this:

Suggested change

	if (!(data instanceof ArrayBuffer) && SharedArrayBuffer && !(data instanceof SharedArrayBuffer)) {
	if (!(data instanceof ArrayBuffer) && (typeof SharedArrayBuffer === 'undefined' || !(data instanceof SharedArrayBuffer))) {

[mourner]

Same issue, typeof

[jdesboeufs]

I finally used global.SharedArrayBuffer to avoid the error and to allow unit testing.

[mourner]

@jdesboeufs global. only works in Node 😅 We could use globalThis, although it's also a relatively recent API. I think the typeof undefined check is the safest option. You could do it once in the top scope and save in a variable.

[jdesboeufs]

I'm definitely a backend developer 🤣

I agree with you for typeof but it make it difficult to test SharedArrayBuffer absence without some kind of dependency injection…

Here is another implementation, using data.constructor.name to detect the object type, and which replace useSharedArrayBuffer by ArrayBufferType (default ArrayBuffer). More consistent with other arguments, less code, and let user inject SharedArrayBuffer by itself (no need to check availability).

As ArrayBuffer and SharedArrayBuffer are native and relatively recent things in JS world, we can consider that obj.constructor.name is OK. If somebody try to create an index from an object without constructor it will have a generic error.

Tell me what to you think! 😅

[jdesboeufs]

I agree with that!

If it's OK feel free to squash. No need to bloat the commit history 🫣

[mourner]

Nice! Thanks for the contribution.