[jitsi-dev] [libjitsi-commits] master: Fixes a deadlock in the SctpSocket. (cc053a7)

Hello, George!

I see that you've elected to not implement a closed flag i.e. to not
defer the closing of the native SCTP socket pointer in case the close
method is invoked by a thread which is already in possession of the
readLock. Does it mean that you believe our current execution graph
does not include such a path? If you're not sure, then I still think
that there is such a possibility and then the close method will not be
able to acquire the writeLock and, effectively, will cause a deadlock.

Best regards,
Lyubomir

Hello Lyubomir!

You're right, the problem's not entirely fixed. Instead of deferring the
closing of the native SCTP socket pointer in case the close method is
invoked by a thread which is already in possession of the readLock
(which is not possible to find out with the stock
ReentrantReadWriteLock, so we would have to roll-out our own solution)
how about releasing the read lock in the socket.onSctpInboundPacket
method? Do you think that would work?

Best regards,
George

···

On 28/10/2014 08:57, Lyubomir Marinov wrote:

Hello, George!

I see that you've elected to not implement a closed flag i.e. to not
defer the closing of the native SCTP socket pointer in case the close
method is invoked by a thread which is already in possession of the
readLock. Does it mean that you believe our current execution graph
does not include such a path? If you're not sure, then I still think
that there is such a possibility and then the close method will not be
able to acquire the writeLock and, effectively, will cause a deadlock.

Best regards,
Lyubomir

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

I think that would endager the SCTP socket pointer. Anyway, I'll
implement the deferring.

···

2014-10-28 11:55 GMT+02:00 George Politis <gp@jitsi.org>:

You're right, the problem's not entirely fixed. Instead of deferring the
closing of the native SCTP socket pointer in case the close method is
invoked by a thread which is already in possession of the readLock
(which is not possible to find out with the stock
ReentrantReadWriteLock, so we would have to roll-out our own solution)
how about releasing the read lock in the socket.onSctpInboundPacket
method? Do you think that would work?