Hello libevent, I am writing to see if I could get clarification on wait conditions and their use with recursive locks.
My first issue is understanding how a custom evthread_lock is supposed to be implemented. evthread_lock_callbacks::supported_locktypes() documentations says "Note that RECURSIVE locks are currently mandatory, and READWRITE locks are not currently used." So I debugged the alloc method of my custom lock and noticed that only a locktype of 0 was being used which I assume is non-recursive. At first, this description made it sound like only recursive locks are requested by the library, but that's not the case. In what cases will the libevent library try to allocate a recursive lock? As a side note, I would suggest that there be like a NONRECURSIVE flag, so that 0 has a clear definition. Secondly, I'm not sure what the behavior of evthread_condition is since using recursive locks and wait conditions has always been tricky (see http://en.wikipedia.org/wiki/Reentrant_mutex paragraph starting with "A big form of criticism on recursive mutexes is that when used in combination with condition variables <http://en.wikipedia.org/wiki/Condition_variable>"). And the custom thread/locking library that I wish to use doesn't even support wait conditions with recursive mutexes. I use QtWaitCondition and it doesn't even really even support waiting on a recursive mutex ("If *mutex * is a recursive mutex, this function returns immediately.", http://doc.qt.nokia.com/4.7-snapshot/qwaitcondition.html#wait). I'm not sure how how I should be implementing this and what it means for libevent. If libevent tries to wait on a recursive mutex, should it actually wait or should it return immediately? The expected behavior should probably be documented. This is problematic since the library I use doesn't support this. Would libevent even run into this situation? Clearly I am confused here and would benefit from some clarification. Any help would be greatly appreciated. Thanks, -Julian
