SLiM
SLiM copied to clipboard
Windows fix for RNG seeding needed
Hi @rdinnager! This is one for you, when you have time. It is not urgent but would be good to get in before the next version ships (which is not presently scheduled and probably not imminent).
In file eidos_rng.cpp
at line 38 (at present), there is a function:
static unsigned long int _Eidos_GenerateRNGSeed(void)
This function is supposed to generate a new seed value for SLiM's random number generator from some operating system source of randomness. For Linux and macOS, it now reads random bits from /dev/random
, a cryptographically secure source of randomness (but very slow, which is why SLiM doesn't use it otherwise). Unfortunately Windows does not have /dev/random
, apparently, so for Windows it still uses the old scheme of hashing together things like the process ID and the current time in milliseconds, which is much less good – so much less good that there is perhaps some risk of multiple runs receiving the same seed value.
I'm not particularly worried about what solution you'd like to use, as long as it will give a different seed value every time it is called, whether within a single run of SLiM or across multiple runs, without depending upon any seed value supplied by the user on the command line etc. This looks like one possibility:
https://en.wikipedia.org/wiki/Entropy_(computing)#Windows
but the seeds don't really need to be cryptographically secure if that API is a pain to use. (But of course if they are, it gives more peace of mind that they will essentially never repeat, so if that API is easy to use then it would be a great choice.)
Thanks!
@rdinnager I'm moving towards a SLiM 4.1 release, so this would be nice to straighten out. Or @bernard-kim, perhaps you have a couple of cycles free? You two are my Windows go-to people now. :-> Or @samchamper maybe?
Hi @bhaller ,
Sorry for being a bit absent lately. I should be a bit more engaged with SLiM in the next few months because I just picked up development of slimr
again after it being on the backburner for a bit (I sent in revision for the manuscript last week, we'll see how that goes). I did look into this a little when you first posted it but wasn't able to immediately wrap my head around it. I was planning on having another go at it but then got distracted by other things. But I should have some time next week where I can have another crack if another solution has not emerged by then.
Good to hear, @rdinnager! Good luck with the slimr
manuscript, that's great! Happy to zoom about this if that would be helpful. I think/hope it will be an easy fix, probably just 1-2 lines of code; the hard part is just finding the correct Windows API in whatever documentation they have for that, which I know nothing about. I'm also glad you're getting re-engaged because I hope to roll SLiM 4.1 soon, and it would be great to get the pacman crank turned properly for that release; I'll be in touch about that, but this is a bit of advance warning. :-> Thanks!
Hi @rdinnager. Just a new ping, since I'm thinking about rolling SLiM 5 some time in the not-too-distant future. It'd be nice to get this issue crossed off. I hope things are going well with slimr
too. :->
Or @samchamper, want to take a crack at this, since @rdinnager seems busy? I think it should be pretty easy, for somebody with a developer setup on Windows; you have that, right? Or are you all Linux now?
@bhaller Sorry I missed your last two pings somehow on this. Yes, I think I am too busy at the moment to do this. Apologies. However, let me know when SLiM 5 is ready to go and I will make sure I make the time to get the pacman installer updated for that!
slimr
is going well. I'm working on second revisions for the manuscript now and I'm pretty optimistic about its chances. It also supports multispecies models now which I'm excited about.
Sounds good, thanks @rdinnager. BTW, looks like I will do a SLiM 4.1 release for now (fairly soon), and SLiM 5 will get pushed out.
@bhaller No worries. I will turn the crank on pacman for 4.1 then. Just ping me when its ready.