Changes between Version 2 and Version 3 of PJSUA_Locks

Timestamp:

Feb 13, 2008 7:53:34 PM (17 years ago)

Author:

bennylp

Comment:

--

PJSUA_Locks

@@ -36 +36 @@
 == Soft Deadlock ==
 
-Although hard deadlock (where application just freezes) should never happen when the above guidelines are used, there may be cases when application gets a ''soft deadlock'' state. When this happens, application will not freeze permanently, but rather it will freeze for few seconds while PJSUA-LIB is trying to acquire the locks, and these message may appear in the log:
+Although hard deadlock (where application just freezes) should never happen when the above guidelines are used, there may be cases when application gets a ''soft deadlock'' state. When this happens, application will not freeze permanently, but rather it will freeze for few seconds while PJSUA-LIB is trying to acquire the locks, and these message may appear in the log afterwards:
 
   ''Timed-out trying to acquire PJSUA mutex (possibly system has deadlocked) in pjsua_xxx''
@@ -46 +46 @@
  1. when PJSUA-LIB tries to acquire locks with {{{acquire_call()}}} on behalf of the worker thread, it will fail to get them because the locks are currently being held by the callback thread (in step no 1 above). In this case, rather than ''deadlocking'' permanently, PJSUA-LIB will timeout after it retries acquiring the locks for few seconds, and returns PJ_ETIMEDOUT error to {{{acquire_call()}}} caller.
 
-This problem is not caused by PJSUA-LIB, and in fact PJSUA-LIB has helped us not to deadlock permanently.
+This is a generic application design problem, and is not caused by PJSUA-LIB (in fact PJSUA-LIB has helped us here by not deadlocking permanently).
 
-As for the solution, quoting the famous saying, I'll leave that as an exercise for the reader. ;-)
+As for the solution, quoting the famous saying: ''I'll leave that as an exercise for the reader''. ;-)