Open proximous opened 7 years ago
Do you have a suggested fix? Or sample code to reproduce non-thread safe behavior?
A fix could be to simply change the geomag.declination call to do the workaround I mention above. I have not looked through the geomag code extensively, so I can't comment on the right/best approach.
It appears the problem is that when geomag is imported, an instance of GeoMag() is created (I assume for performance), and every call to geomag.declination() uses that same instance. Therefore, if multiple threads are calling geomag.declination(), you can get into the race condition where one thread gets the result from another thread, because each thread is talking to the same GeoMag() instance. My workaround avoids this by using a unique GeoMag() instance for every calculation.
I don't have a minimal set of code to offer to reproduce the issue, but I effectively had a situation where my lat/lon values were 'nan', which results in a declination of 'nan'. In my other thread, I had the declination sometimes resulting in 'nan', which was easy to notice and impossible to replicate from the command line with valid non-nan floats. That got me on the path of realizing that the 'nan' was coming from the other thread. I assume you could simply create multiple threads that should produce a known declination, and then run the threads in a loop, perhaps with some random delays, and then test that you always get the known result. With the exact timing in my system, I was calling two threads around 10 times a second, and I'd get three or four collisions in 10 seconds.
Good feedback. That gives me something to go on. Some sample code to reproduce the problem would be great!
My application uses threads, and I discovered that geomag.declination() is not threadsafe and resulted in me calculating incorrect declinations.
Perhaps this is 'by-design', but if so it should be documented.
As a work-around, I switched my call to: geomag.geomag.GeoMag().GeoMag(latitude, longitude).dec