bryancall commented on code in PR #13027:
URL: https://github.com/apache/trafficserver/pull/13027#discussion_r2999122421
##########
src/proxy/http/HttpProxyServerMain.cc:
##########
@@ -376,4 +376,16 @@ stop_HttpProxyServer()
{
sslNetProcessor.stop_accept();
netProcessor.stop_accept();
+
+ for (auto &acceptor : HttpProxyAcceptors) {
+ delete acceptor._accept;
+ acceptor._accept = nullptr;
+ }
+ HttpProxyAcceptors.clear();
+
+ delete plugin_http_accept;
+ plugin_http_accept = nullptr;
+
+ delete plugin_http_transparent_accept;
Review Comment:
No double-free here. `naVec` contains `NetAccept` objects created internally
by `main_accept()`. The `acceptor._accept` pointers in `HttpProxyAcceptors` are
the higher-level protocol acceptors (`SSLNextProtocolAccept`,
`ProtocolProbeSessionAccept`, etc.) that are passed *into* `main_accept()` as
the continuation. Different objects, different types, different ownership.
##########
src/api/InkAPI.cc:
##########
@@ -7067,11 +7067,13 @@ TSAIORead(int fd, off_t offset, char *buf, size_t
buffSize, TSCont contp)
pAIO->aiocb.aio_buf = buf;
pAIO->action = pCont;
pAIO->thread = pCont->mutex->thread_holding;
+ pAIO->from_api = true;
if (ink_aio_read(pAIO, 1) == 1) {
return TS_SUCCESS;
}
+ delete pAIO;
return TS_ERROR;
Review Comment:
Fair point on consolidation. The existing `fromAPI` parameter controls AIO
queue/filedes routing behavior, while `from_api` on the object controls
lifecycle (who is responsible for deletion). They happen to correlate today but
serve different purposes. Setting `from_api` inside `ink_aio_read/write` based
on the `fromAPI` arg would be cleaner — will consider as a follow-up refactor.
--
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]
