Potential deadlock on peer destruction
There appears to be a potential deadlock when a peer is destroyed at just the right (or wrong :)) time.
Descriptions are against code at tag: v0.2.8-rc1
Thread1: receiver_pthread_protocol
- on entry to the
while
loop (rist-common.c(3891)), acquires the flow mutex. * - in the
session_timeout
condition (rist-common-c(3917)), tries to acquire thepeerlist_lock
mutex. **
Thread2: rist_peer_destroy
instigated from the client app.
- acquires the
peerlist_lock
** -
rist_peer_remove
(rist-common.c(3497)), tries to acquire the flow mutex. *
(Thread3): receiver_pthread_dataout
- is trying to acquire the flow->mutex after waking/timeout.
Reproduced by brute-force soak, with repeated connect/data-flow/disconnect test (caller/input, listener/output).
I'll try to manufacture a reproduction code snippet, but it looks like the locks taken in Thread1/Thread2 highlight the deadlock.