Add glecuid#234
Conversation
|
Hello! Thank you for the addition! I was reading the source and I noticed there's a large chunk of vendored code, but I couldn't identify how the users of this library would get alerted to security vulnerabilities for this code, and how they would get security patches for it, seeing as it has been isolated from the upstream source. How do you recommend they deal with this? The counters lack sequential consistency on Erlang and thread safety on JavaScript, so you can get collisions with these numbers. Wouldn't this result in collisions with the generated ids? |
|
Hi, thanks for reviewing the code. For the vendored code is there an official way for including javascript dependency? On Erlang counters perhaps I should use the EDIT: I've addressed some of your concerns in the next branch. For Js dependency, I think better way to do it is to instruct the user to get it from npm instead of vendoring it. |
Having people run
Atomics are always good if you can use them! They've much faster than all the other options.
Each JS thread will have their own copy of the counter, so multiple threads can get the same value at the same time. |
|
Vendored codes are removed on v2.0.0 and instruction to get the dependency is added to readme.
This won't cause collision, because each copy of the counter will be initialized with different starting value. |
|
I just had a look and it's using the private API for constructing Gleam types. The public API is documented here: https://gleam.run/documentation/externals/ |
|
Fixed |
No description provided.