saimayithri commented on issue #13358: URL: https://github.com/apache/trafficserver/issues/13358#issuecomment-5010889719
Thanks for the clarification @JosiahWI that helped clear up my misunderstanding about thread vs. thread_holding. I traced the HTTP/2 code paths a bit further and noticed what appears to be a difference in execution context. From what I can tell, normal VC_EVENT_READ_READY / VC_EVENT_READ_COMPLETE processing reaches do_process_frame_read() via NetHandler::waitForActivity(), where nh->mutex is already held. In that case, the later MUTEX_TRY_LOCK in add_to_active_queue() succeeds recursively because the current thread already holds nh->mutex. In contrast, HTTP2_SESSION_EVENT_REENABLE appears to execute from EThread::process_event(), where only the session continuation mutex is acquired before entering do_process_frame_read(), and nh->mutex is not already held. Is my understanding of those execution paths correct? If so, is there an intentional reason why the re-enable path executes without the NetHandler locking context, even though it can eventually reach add_to_active_queue()? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
