I was looking at the annoying problem with SipSrvLookupTest, viz., now that the different DNS record types are retrieved on different threads, the randomization of scores is no longer predictable, making it difficult to write reliable tests. I think I've got a solution to this problem, but I want everyone to help me think this through.
I first started reading the srand() manual page. It includes information on rand(). It turns out that rand() isn't thread-safe, which isn't very surprising, since rand() has an internal state variable. Although I don't expect that anything bad happens if one calls it simultaneously from two different threads -- it's a random-number generator after all. But if we're going to respect the rules, we need to replace the use of rand() with rand_r(&state_variable), with a separate state variable for each thread. (Make sure we initialize the state_variables with different values; otherwise the four threads will each generate the same sequence of random values.) If we do that, then SipSrvLookupTest can force the random numbers to be reproducible by, at the beginning of each test, setting each of the four state variables to fixed values. Another approach would be to remove the calculation of "score" (which uses rand()) from server_insert(), and instead, have SipSrvLookup::servers() do it just before sorting all the answers. To make the result deterministic for testing, we'd need to first sort all the answers in some way, then calculate the scores, then sort the answers based on score. The first sort could easily be made optional, to only be activated for testing. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
