If a stopwatch is access via statman in a multi threaded env, I expect that there would be concurrency issues:
(in t1) Statman.stopwatch('sw').start()
#t1 do stuff
(in t2) Statman.stopwatch('sw').start()
(in t1) Statman.stopwatch('sw').stop()
#t2 do stuff
(in t2) Statman.stopwatch('sw').stop()
The shared sw will have start time at t2.start and endtime at t2.stop. In history will be t2.start to t1.stop and t2.start to t2.stop.
Rather, on Statman.stopwatch( thread_safe ) or general Statman thread safe option, return two separate child stopwatches not recorded in history. Statman pass a history object from parent to child, so that when .stop occurs it writes to a common history.
The consumer will be forced to hold a reference:
(in t1) sw = Statman.stopwatch('sw')
(in t1) sw.start()
#t1 do stuff
(in t2) sw = Statman.stopwatch('sw')
(in t2) sw.start()
(in t1) sw.stop()
#t2 do stuff
(in t2) sw.stop()
Will need to update @timer to pass threadsafe flag.
If a stopwatch is access via statman in a multi threaded env, I expect that there would be concurrency issues:
The shared sw will have start time at t2.start and endtime at t2.stop. In history will be t2.start to t1.stop and t2.start to t2.stop.
Rather, on Statman.stopwatch( thread_safe ) or general Statman thread safe option, return two separate child stopwatches not recorded in history. Statman pass a history object from parent to child, so that when .stop occurs it writes to a common history.
The consumer will be forced to hold a reference:
Will need to update
@timerto pass threadsafe flag.