Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
In fact, why is there a lock in on_success and on_failure at all?
To make sure that callbacks are called exactly once per failure/success.
Can you explain that better? The only issue I can see is 1) it failes the state check 2) a different thread changes the state and consumes the array 3) cb is added to the array and never executed.
Correct, that's the issue we're covering.
Now, this can't happen as there is no function call between the state variable check and the array append.
Maybe. I try to make the code I write futureproof by not assuming when Pike can switch/run threads. I.e. currently the only assumption I make is that ++x and x++ are atomic.
And even if we were to assume that current Pike does not allow a context switch in between, then it would still be somewhat tricky to rely on that; anyone changing the code then needs to be aware that they should not cause implicit or explicit context switches in between.
Even if it could happen, a mutex in on_success/on_failure wouldn't help, as it is access to the state variable that needs to be guarded.
The current code *does* guarantee it. The state change is protected, but also when the state is changed, it is guaranteed that all registered callbacks will be called exactly once. So by protecting this check in on_success(), it ensures that it will get the callback registered *before* finalise() is able to change the state.