res_musiconhold: Appropriately lock channel during start. #1104
Conversation
This relates to asterisk#829 This doesn't sully solve the Ops issue, but it solves the specific crash there. Further PRs to follow. In the specific crash the generator was still under construction when moh was being stopped, which then proceeded to close the stream whilst it was still in use. Signed-off-by: Jaco Kroon <[email protected]>
github-actions
bot
added
pr-submit-testing-in-progress
pr-submit-tests-passed
and removed
pr-submit-testing-in-progress
labels
|
cherry-pick-to: 20 |
| ast_channel_lock(chan); | ||
| state = ast_channel_music_state(chan); |
There was a problem hiding this comment.
Can we just do this (and the unlock) one time at the top of the function? Or do we need to serialize all access to state?
There was a problem hiding this comment.
I suspect there's potentially some long-running sub-tasks which is why I went a bit more granular.
There was a problem hiding this comment.
Good question. You know better than me. I didn't dig into this much further beyond this specific PR, life happened and I deviated from this. My gut was that the construction of some of these generators could be time-consuming, and that that could have adverse impact on the channel structure.
But yea, if any of those do take overly long, it's going to be the case that the channel gets no audio anyway, and it would most likely be signalling stuff that just waits for a "long" duration, and that's probably OK if those gets blocked for a few hundred ms.
Based on that, sure, I think I can resubmit with "lock at top, release at bottom" and we see what happens?
This relates to #829
This doesn't fully solve the Ops issue, but it solves the specific crash there. Further PRs to follow.
In the specific crash the generator was still under construction when moh was being stopped, which then proceeded to close the stream whilst it was still in use.