jpeach commented on code in PR #9825:
URL: https://github.com/apache/trafficserver/pull/9825#discussion_r1230308919
##########
iocore/net/UnixNetProcessor.cc:
##########
@@ -259,19 +260,11 @@ UnixNetProcessor::connect_re_internal(Continuation *cont,
sockaddr const *target
}
}
-Action *
-UnixNetProcessor::connect(Continuation *cont, UnixNetVConnection ** /* avc */,
sockaddr const *target, NetVCOptions *opt)
-{
- return connect_re(cont, target, opt);
-}
-
-struct PollCont;
-
// This needs to be called before the ET_NET threads are started.
void
UnixNetProcessor::init()
{
- EventType etype = ET_NET;
+ naVecMutex = new_ProxyMutex();
Review Comment:
>
> It's not intuitive to me that the NetProcessor should be responsible for
initializing this mutex, which is defined in UnixNetAccept.cc. I recommending
leaving the initialization in `main` as before.
I agree that it's not great, but it is better than doing it in
traffic_server.cc, whi8ch has no business at all knowing about how internal
iocore variables need to be initialized. UnixNetProcessor has some reason to
know this since it is the one that knows how to create UnixNetAccept. I'll
think about how to clean this up in a separate PR.
> Alternatively, if you move `naVec` and `naVecMutex` inside of
`UnixNetProcessor`, then this would be a good place to initialize `naVecMutex`.
OK, I don't mind doing that, since UnixNetProcessor actually populated the
vector.
--
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]
