On Mon, 16 May 2022, Luke Small wrote: > 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.
Just to bring this back to where we came in: even putting thread-safety aside (which you absolutely can't): it doesn't matter how much faster it is, your replacement function isn't useful until you do the work to demonstrate correctness. You have done literally zero so far, not even the bare minimum of testing the output. As a result your first version was demonstrated to be completely broken by literally the most basic of possible tests, a mere 10 lines of code. That you left this to others to do tells me that you fundamentally don't understand the environment in which you're trying to operate, and that you don't respect the time of the people you're trying to convince. Please stop wasting our time. -d
