yes, it is known issue, since at cloud configuration time incoming and outgoing TLS connections occur simultaneously, and g_sslContextMutex and g_mutexObjectList locked in different order for send and receive operations. This is architecture issue and network stack should be refactored... I made the workaround - https://gerrit.iotivity.org/gerrit/25341, it solve a deadlock, but I think this solution isn't quite proper and remains only as workaround. Imho, the simplest solution is to use read/write lock of g_mutexObjectList on network stack layer, since deadlock happens on access to network connection list.
Regarding slowdown issue from item 2 - it's another known issue, network layer operates only with sync calls to sockets. For udp it doesn't create issues, but it's critical for outgoing tcp connection - since all network stack will hang & wait on socket timeout.
|
|
_._,_._,_
Links:
You receive all messages sent to this group.
View/Reply Online (#9901) |
Reply To Sender
| Reply To Group
|
Mute This Topic
| New Topic
Your Subscription |
Contact Group Owner |
Unsubscribe
[arch...@mail-archive.com]
_._,_._,_