On May 25, 2010 at 17:10, marius zbihlei <
marius.zbihlei@1and1.ro> wrote:
> Andrei Pelinescu-Onciul wrote:
> >On May 20, 2010 at 13:53, marius zbihlei <
marius.zbihlei@1and1.ro> wrote:
> >>Forwarded the message from sr-users to sr-dev list
> >>
> >>Cheers
> >>Marius
> >
> >[...]
> >>Hello
> >>
> >>I am a little busy atm, so before I dig into the code, I have a
> >>question for core devs. Is the LOCK_HASH() call recursive (being
> >>called again from the same process will not block) ? I ask this
> >>because in the 4th blocked INVITE the hash _might_ be blocked by
> >>both t_newtran(#16 0xb7b535fa in t_newtran (p_msg=0x81f18a8) at
> >>t_lookup.c:1064)
> >
> >No it's not recursive (it will deadlock if called twice for the same
> >entry in the same process). This is true for all *ser versions
> >(sip-router, kamailio < 3.0, ser *).
> >
> Hello Andrei
>
> I have looked thru the code and it seems this is the case. While the
> transaction is locked in t_newtrans(), the tm callbacks are called,
> which call the pua_dialog callback, which in turn call a transaction
> function that requires the same lock; so the mutex is locked twice
> from the same process. Is there anyway we can prevent this from the
> future? One way is to patch pua_dialog so it doesn't call t_uac()(?)
> but this still leaves the possibility of another lock happening
> somewhere else. I was thinking that a better approach was
> implementing a recursive mutex.