Dear PJSIP List / Maintainers,
As I've just been through debugging a deadlock in our application using Pjsip / pjsua2, I would like to suggest a documentation improvement, that should help other users run into the same trap as we did.
In our case, we've implemented some code in the pj::Call::onCallState() callback, that used a Mutex to modify our application state. Another thread, which took the same application state mutex, called out into PJSIP with the mutex held. It was an innocent call::getInfo() with our own Mutex held, but PJSIP deadlocked on this pattern in some, very rare, cases.
To make develoeprs aware, I would suggest improving the pj::Call::onCallState() documentation as follows:
"
| inlinevirtual |
Notify application when call state has changed. Application may then query the call info to get the detail call states by calling getInfo() function.
Note that the callback is made with the PJSUA_LOCK held. So the code should not take any resources that other Threads hold while calling into PJSIP.
- Parameters
prm Callback parameter.
References PJ_UNUSED_ARG.
"
What do you think?
Martin
_______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip@xxxxxxxxxxxxxxx http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
