Yeah, I see your point. I suppose it depends on how conservative you want to be and whether you want to supply options to people like getchar_unlocked when it isn’t essential.
It could be made manually fork-safe if I could make a simple feature where “arc4random_uniform_unlocked(0);” with a 0 upperbound could trigger a reset of the static variables rand_bits and rand_holder which would be simple enough and could be added to a man page. I certainly read the man pages. (I’m surprised “man getchar” doesn’t “see also” to getchar_unlocked() by the way.) If you look at profiling with programs that call it a lot, arc4random() inside arc4random_uniform() calls the expensive rekey function which makes it take more time. That’s why I can get around 2X-3X performance on a typical repetitive small upperbound loop and an extra 20% improvement on a single 65536 Knuth shuffle, loop even though my function repeats a binary search for ‘bit’ size every single time and has misses which demands calling up more data. Otherwise my function would be particularly useful when there’s a loop with small upperbound like: 26+26+10 which, if I recall correctly, is in identd, which would call it frequently. I have a project that I generate MANY random record names much like that and I use fork()/fork()-exec() on many processes well before calling randomizing functions. Maybe I’m not the only one. I don’t want to even try multithreading, especially as often as you guys say that it is too unpredictable. I believe you. Using lua scripts in multi-worker-process redis calls to avoid race conditions is awkward enough for me. But otherwise it’s certainly your prerogative to not have it. At least you can’t legitimately say that it adds too much extra code or is too complex. It’s pretty simple to understand if you’re familiar with bitwise stuff. On Mon, May 16, 2022 at 5:35 PM Stuart Henderson <s...@spacehopper.org> wrote: > On 2022/05/16 15:13, Luke Small wrote: > > If you’re not running a threaded program, my function wouldn’t be “less > > safe.” > > > > I’d imagine that 99% of programs aren’t multithreaded. > > code is reused in different places. non threaded programs are sometimes > turned into threaded programs and when that happens, sometimes > non-thread-safe calls are missed. so i'd argue that it is still less > safe. > > in some cases there might be benefits that would mean it's worth it, > especially if the failure modes would be obvious such that they can > be detected. really not seeing that here. (how often are you even > calling arc4random_uniform to consider it slow?!) > > if the consequence is not a crash but instead subtly broken randomness, > how long do you think it's going to take to notice and report/fix it? > even *very* broken randomness in widespread software distributions > has been known to sit around for a long time before it's noticed: > > - predictable rng in a popular os. *serious* bug. introduced 2006, > discovered/reported nearly 2 years later. > > - non-fork-safe rng in a popular ssl library, introduced sometime before > sept 2018, reported may 2019. > > -- -Luke
