precomputed object doesn't contemplate multiple modules

[twiddlingbits]

In twrConCanvas, precomputed objects does not contemplate the fact that consoles should support multiple wasm modules (one or more, any mix of, twrWasmModule, twrWasmModuleAsync). For an example of multiple modules using a single console, see the multi-io example.

For example, a precomputed ID could have a collision if two different modules used the same ID.

Please add another test case to mult-io that triggers the bug. Then fix.

One approach would be to OR the twrLibrary Instance ID into the precomputed key (and make the key 64 bits?)

There may be other issues related to the multiple module case -- i haven't thought much about it.

[JohnDog3112]

What ID would I use? There's this.id for the twrConCanvas class, however, I was under the impression that that was just the ID of the library itself, independent of the calling module. Unless a new twrConCanvas object is created when passing it into a twrWasmModule, I don't see how I would be able to tell them apart.

[twiddlingbits]

you are correct about the library id. That was a bad suggestion on my part.

Any other ideas?
Other ideas:

• add an id to IWasmModule/Async (use a static counter)
• keep a mapping of module instances to a numeric id in twrConCanvas

[JohnDog3112]

I feel like adding a static counter to IWasmModule/Async would be best. That way any programs that need to differentiate between clients can use it.

[twiddlingbits]

i agree. One of us can do that at some point.

[JohnDog3112]

For now, I've implemented a static counter function in twrmodbase.ts (probably not the best place), and added an id field to both IWasmModule and IWasmModuleAsync which calls the function to get their ID's.

One approach would be to OR the twrLibrary Instance ID into the precomputed key (and make the key 64 bits?)

I think that would work, there's just a couple oddities to keep in mind:

• When using the base number, left shift and bitwise or operations treat number as a 32-bit, signed integer
• If you bypass that by using multiplication and addition instead, you are capped at 52-bits before you start losing precision since number uses a 64-bit float with a 52 bit mantissa.
• Alternatively, BigInt can be used in stead of number. Operations on it are slower than number, however, I'm not sure it's by enough to matter.

Another implementation (that might be easier) would be to make them 2d arrays. That way the first index is the module id and the second is the id given from C.

For now, I'll implement it as a 52-bit key with 32-bits for objects and 20-bits for numbers.

[JohnDog3112]

If we stick with using an extended key, should there be a function for it under the WasmModule and WasmModuleAsync interfaces? Right now, I have a separate function that takes in the module and id and returns the combined id/key. However, it would probably be better suited under those so you can just do mod.combineID or mod.combineKey(id/key). I'm just not sure how much functionality is intended to be under those two interfaces especially since they're currently separated.