Separate rand_thread crate?

[dhardy]

Synopsis: create a new rand_thread crate to house ThreadRng and make rand depend on that.

Motivation:

• various users claim they only want this part of rand Depdendency explosion #713 Could rand changes slow down and simplify the API before making new versions? #704
• it is logically isolated functionality, thus easy to split out

Reasons not to do this:

• this crate would only have 1-2 less dependencies than rand — rand_pcg (which might be removed from rand anyway) and possibly autocfg
• this is yet another crate for users of Rand as a whole
• likely someone would want some extra functionality, such as generating uniform integers within a given range, and thus have to add a dependency on rand anyway (or roll their own code which is easy to get wrong with bias and off-by-one errors and would miss our various specialisations and optimisations)

To be clear: my personal opinion is that we don't need this.

[vks]

I'm also not convinced by the arguments for this separation. A better way forward might be to reduce the code in the rand crate, which is currently planned anyway (see #715).

[newpavlov]

I believe ThreadRng should go into it's own crate. It's a perfectly isolated piece of functionality and there are users who use only it, without any additional functionality provided by rand. Also in my opinion it will be inconsistent and a bit surprising to keep every RNG in its own crate, but not ThreadRng.

[dhardy]

Two "votes" against this, one for. I would appreciate more users commenting on this.

[nagisa]

My feeling is that threadrng is actually a wrapper and that it is more of a building block (much like the traits are) rather than an Rng in its own right. Against, but could be persuaded otherwise.

…

On Mon, Jan 28, 2019, 19:12 Diggory Hardy ***@***.*** wrote: Two "votes" against this, one for. I would appreciate more users commenting on this. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#716 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AApc0jwtmcg8eWwTu-lAX_UC_hFmbaowks5vHy9ngaJpZM4aVzl7> .

[newpavlov]

threadrng is actually a wrapper and that it is more of a building block

I think you misunderstand something, essentially ThreadRng is a "default" RNG. If applications don't have strict security requirements like "use only OS RNG", or performance requirements (so very-very fast non-cryptographic RNGs will be a better fit) like games or simulations, they usually will use ThreadRng as the only source of non-deterministic random data. (via thread_rng or random)

[burdges]

Another alternative might be:

• migrate ReseedingRng from rand to either rand_core or more likely rand_os, and
• migrate ThreadRng to rand_os.

I've forgotten any discussion around ReseedingRng's placement, but if it creates no problems then the only cost here would be rand_os users needing to compile rand_chacha or AESNI whatever, but the linker should avoid that actually appearing in code that never touches ThreadRng.

At this point, we'd have roughly this breakdown:

• rand_core - Only used directly when writing CSPRNGs.
• rand_os - Bytes or word oriented system randomness users, either with or without the per-thread ReseedingRng optimization. All OS abstraction handled here unless getrandom happens.
• rand - Anything higher level around sampling and distributions.

[dhardy]

Interesting @burdges. It might be worth coming back to this idea once we have a fully-functional getrandom for those who just want entropy.

[dhardy]

Sounds like we're mostly in agreement to keep thread_rng within the main Rand crate. We can revisit given fresh rationale, but I see no reason to keep this open now.