On 10/11/14 10:28, Olle E. Johansson wrote:
> On 10 Nov 2014, at 10:26, Daniel-Constantin Mierla wrote:
>
>> On 07/11/14 22:54, Alex Balashov wrote:
>>> On 11/07/2014 04:45 PM, Daniel-Constantin Mierla wrote:
Using sht_lock() and accessing an item on the same slot is ending up in
a dead
On 10 Nov 2014, at 10:26, Daniel-Constantin Mierla wrote:
>
> On 07/11/14 22:54, Alex Balashov wrote:
>> On 11/07/2014 04:45 PM, Daniel-Constantin Mierla wrote:
>>> Using sht_lock() and accessing an item on the same slot is ending up in
>>> a deadlock.
>>>
>>> Should be avoided for the moment
On 07/11/14 22:54, Alex Balashov wrote:
> On 11/07/2014 04:45 PM, Daniel-Constantin Mierla wrote:
>> Using sht_lock() and accessing an item on the same slot is ending up in
>> a deadlock.
>>
>> Should be avoided for the moment -- I didn't have time to look for a
>> solution with the work on releas
On 11/07/2014 04:45 PM, Daniel-Constantin Mierla wrote:
Using sht_lock() and accessing an item on the same slot is ending up in
a deadlock.
Should be avoided for the moment -- I didn't have time to look for a
solution with the work on releases during the past days.
The share hash table is avail
Using sht_lock() and accessing an item on the same slot is ending up in
a deadlock.
Should be avoided for the moment -- I didn't have time to look for a
solution with the work on releases during the past days.
The share hash table is available to all processing, the access to items
is synchronize
PS. I appear to have encountered the same deadlock problem as Savolainen
Dmitri:
http://lists.sip-router.org/pipermail/sr-dev/2014-November/026046.html
On 11/07/2014 04:02 PM, Alex Balashov wrote:
The documentation for the htable module gives no guidance on whether
sht_lock()/unlock() should
