New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make UUIDGen
more performant
#2882
Comments
http4s/http4s#6138 is another hidden instance of this problem. Maybe what we really need is a way of safely and efficiently generating random bytes. UUIDGen, and this http4s use case, could both build on that. |
Yes, I've wondered if we need a |
Ross has demoed his proposal in http4s/http4s#6165. |
I rather like Ross' proposal. |
I reformed it a bit to add the pool. This is a win when we get caught in a mutex, which we always will in Java 8. In Java 9, if we have a non-blocking but threadsafe instance, we probably don't want that pool. But detecting thread safety is super gross. |
Would I can imagine a marker trait being useful, so a random client can express that it needs something stronger. |
I was thinking marker trait. I see the JDK https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/SecureRandom.html |
I have found |
Btw, another good reason to implement |
Uh yes, that's a relatively serious issue. |
Hey! I want to take this ticket, I'm just wondering what would be the final solution here.
Using our own implementation of SecureRandom and them reimplement the steps done on
|
Hi @diogocanut, great! Good question, I think there are two changes we need to make:
|
Hm, I'm wondering if the (Of course the other thing, JVM 8 using |
Uhh, |
Here's a potentially mad idea ... could we just implement our own secure random by reading from |
I thought about that, but it seems like a can of worms (although if someone wants to open it, I definitely won't stop them):
|
Fallback to the current scheme: use JDK
Yeah ... and I think you are right that
Yeah, this seems the most promising avenue, based on the article you linked. In light of above, my best ideas are:
|
Oh, right, here it's possible to just fall back to
I think this option has the advantage of also working on older Linux. (Fallback could be smarter, e.g., detect if we have a sufficiently modern OS that the dance with reading-writing is not necessary, ...) |
Also, there is a JDK built-in |
As of #2880 it delegates to
Sync#blocking
.Some ideas in #2865 (comment) to improve the status quo:
The text was updated successfully, but these errors were encountered: