@vingarzan commented on this pull request.
> @@ -367,9 +366,7 @@ int sm_process(
p->state = R_Open;
break;
case R_Rcv_Message:
- // delayed processing until out of the
critical zone
- //Rcv_Process(p,msg);
- msg_received = 1;
+ Rcv_Process(p, msg);
Calling the handlers with the lock is maybe a bad idea. Sure, there is a
"task-queue" in-between this process and the one actually doing the handling
and potentially sending a message out to the same peer, but you are changing
the "contract" which other functions relied on, that the peer wasn't locked.
I left a bigger description though why having a pointer to the peer in
`Rcv_Process()` is also a bad in the absence of a locked peer p. Hence we
probably need to change the APIs, not the locking strategy here.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4191#pullrequestreview-2727969134
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4191/review/2727969...@github.com>_______________________________________________
Kamailio - Development Mailing List -- sr-dev@lists.kamailio.org
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
