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


#1

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


#2

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


#3

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?