This fixes Android build after #1448 was merged.
This does not exactly the same thing as on other platforms but I'm not sure how to handle it best. Calling srand() with the same number for every call to GetRandomNumber() will always result in the same number being returned from rand(). Calling srand() with time(NULL) as an argument would probably work but the numbers generated in sequence aren't really random either because there's a different seed for every number. And if multiple calls to GetRandomNumber happen within the same second we have the same problem that all the numbers returned by rand() will be the same.
The problem is that srand() and rand() are thread-local and GetRandomNumber can be called from different threads. I'm not sure myself how to solve this.
Well... I thought that s_randomSeed is randomized over time. But I didn't check.
I think that calling srand with time(NULL) should be ok until a better solution is found. At least the build isn't broken..
Android/Bionic doesn't implement rand_r
srand is not reentrant or threadsafe. So you would need to lock afaict
What do you think about simple add rand_r implementation manualy?
Like this: http://gitorious.org/android-pc/external-sshfs/commit/dca49dbc512de2c9dd170d2e402048e7db540ecf
We don't want to maintain libc. This might be a case for our second line of java. :( Thoughts @theuni ?
Just a thought... What about using Boost.Random? Boost is already a dependency...
Boost.Random does not maintain global state that would need protection from multi-threading.
Boost.Random is thread-safe as long as you don't access any given object from two threads simultaneously. (Accessing two different objects is ok, as long as they don't share an engine). If you require that kind of safety, it's trivial to roll that on your own with an appropriate mutex wrapper.
nak on using Boost.Random
adding the source for rand_r into android specific's might be the best until Google sees a need to add it.
We don't want boost.random, our current boost usage is header-only, and we need to keep it that way.
I actually prefer fape's proposal, but tweaked a bit. We already need the crystax ndk to build, and I've had the suspicion for a while that we'd need to modify it eventually. Looks like this is it. In fact.. one of our deps (samba maybe?) I've already had to hack to bypass rand_r.
Edit: Posted a request for crystax, maybe we can avoid forking for now. See here: http://www.crystax.net/trac/ndk/ticket/102
Until then, I'm ok with adding it the same way we added getdelim.
Update: see above link, crystax will add rand_r for the next release. I'm going to create a ticket for getdelim as well.
For now, I added a local version in 92e2a05.
Improved token verification behaviour.
PHT will now handle the token being reset from plex.tv much more
reliable. In the process MyPlexManager also logs much better
information on errors.