From: Jan N. <jan...@gm...> - 2015-06-16 15:34:54
|
2015-06-16 17:24 GMT+02:00 Joe Mistachkin <sf...@mi...>: > I think it should be fairly easy to prove that it is impossible to create a > deadlock with [exec] and the new TIP. > > In fact, I think the torture test that Gustaf came up with helped > demonstrate > that quite well (i.e. it had 100 threads calling [exec] 1000 times each). Gustaf's tests are a strong point, 'proving' that the thread handling in the new implemention is correct. I'm willing to believe his results. But there was another question unanswered: 2015-06-10 16:36 GMT+02:00 Donald G Porter <don...@ni...>: > I'm also sorry to raise a new question with voting already started, > but... > > With all the additional lock synchronization added to the AtFork*() > dance in the unix notifier, is there still a need for the new > routine, Tcl_MutexUnlockAndFinalize() at all? I'm not convinced that Tcl_MutexUnlockAndFinalize() needs to be exported, it could as well be an internal function TclpMutexUnlockAndFinalize(): <http://core.tcl.tk/tcl/info/c2af0457badfed61> Advantage: no TIP is required to fix Gustaf's bug, backporting to 8.5 can be done as well without violating our own rules. Then, the exposure of the new function is the only part of the TIP that still needs to be voted on, it can be delayed until Tcl 8.7 (or 9.0). It needs a use-case in order to be convincing, but that's all. Regards, Jan Nijtmans |