vthiery
further threadsafety hardening
over in #12 we've clarified a few things to make the library threadsafe. there are a couple more little things to finish the job though largely the library is already threadsafe. this pr makes the use of the rng threadsafe by using thread local storage. additionally we remove the ability to change the internal state of the client via setConfig and seed. you're only option for configuration is up front or to make a new client which is certainly a clearer contract
the only thing left to do is fix the tests since the api has changed some of the tests are hard to keep in their current form
fixes #12
@vthiery i dont know if you have any time to look at this but basically in recent times people are asking about threadsafety again and so this is the last little cleanup needed to make the library fully threadsafe again. more info in #12 and also #53
Thank you for the work @kevinkreiser ! I have to admin that I've only been following this distantly, but I'll review asap.
well i saw your ship and so i went to edit the docs to say that the library is thread-safe but upon review i think there is still one thing to do which is to make the sender thread-safe even when the sending interval is 0.
see in most use-cases you would make use of the sending interval to spawn the background sending thread and the library is then thread-safe HOWEVER when the sending interval is 0 we expect you to call flush manually to send your messages over the socket BUT in this case we acquire a dummy lock (no thread-safety).
therefore if you configure your client with send interval 0 but you share the client in multiple threads who all race to call flush you will have thread-safety issues. i'll review the udpsender header further to make sure we remove the rest of the thread-safety pitfalls before asking for another review! apologies!