Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
@vingarzan commented on this pull request.
In src/modules/cdp/peerstatemachine.c:
> @@ -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, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.