-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
network: delegate file event creation to io handle #12720
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -69,9 +69,9 @@ ConnectionImpl::ConnectionImpl(Event::Dispatcher& dispatcher, ConnectionSocketPt | |
|
||
// We never ask for both early close and read at the same time. If we are reading, we want to | ||
// consume all available data. | ||
file_event_ = dispatcher_.createFileEvent( | ||
ConnectionImpl::ioHandle().fd(), [this](uint32_t events) -> void { onFileEvent(events); }, | ||
trigger, Event::FileReadyType::Read | Event::FileReadyType::Write); | ||
file_event_ = socket_->ioHandle().createFileEvent( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: The RELEASE_ASSERT in line 62 above may make more sense in IoSocketHandleImpl::createFileEvent, DispatcherImpl::createFileEvent or FileEventImpl so we can remove the call to the ioHandle fd method. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was actually planning a separate PR that removes all of those asserts! Should I do this one in particular here or is it fine if we postpone it to the next PR? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Next PR is fine. |
||
dispatcher_, [this](uint32_t events) -> void { onFileEvent(events); }, trigger, | ||
Event::FileReadyType::Read | Event::FileReadyType::Write); | ||
|
||
transport_socket_->setTransportSocketCallbacks(*this); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The long term plan continues to be to completely remove "fd" from all top level dispatcher interfaces, right? My main concern is there is nothing right now that prevents not calling the original FileEvent factory function with the IoHandle fd, right? Can we add relevant comments around usage, TODOs for eventual removal, warnings, etc.? My quick take would be that if we have a similar function on the filesystem interface we might be able to completely remove the public interface that allows file event creation from fd sooner rather than later (I'm not sure what else actually uses that factory currently)? wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's exactly right. The goal is to use IoHandles instead of fds whenever possible.
Apart from the sockets, others that use the dispatcher's original
FileEvent
factory function are:WatcherImpl
, which creates inotify events using raw fdsDnsImpl
, which relies on raw fds from AresHotRestartingParent
, which also uses raw fdsIn theory, we can change all of these, including
IoSocketHandleImpl
to allocateFileEventPtr
s directly and then completely remove the dispatcher's public interface. The only thing we'll miss out on is theisThreadSafe()
check, but maybe we can make the function public? I can take care of this but should we do it as part of this PR or a separate one?Finally, out of those 3, maybe we should update at least
DnsImpl
to useIoHandles
(not sure if that's easy).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer we just do it now if you are up for it, but if you feel strongly we can do it as a fast follow up?
Yeah that would be nice. Maybe add a TODO there for follow up later?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was about to start work on it but it turns out
FileEventImpl
depends onDispatcherImpl
and all is bundled in//source/common/event:dispatcher_lib
. Trying to add the latter as dependency to thedefault_socket_interface_lib
quickly runs into circular dependencies. I guess this is because we don't want to expose the scheduler's implementation, i.e., libevent'sevent_base
, in the dispatcher's interface.Unless there's a smarter way, we'll have have to separate
FileEventImpl
fromDispatcherImpl
and that might not be trivial (they'd have to exchange libevent specific objects over generic apis). The alternative would be to still use the dispatcher as aFileEvent
factory and work towards removing the fd fromIoHandle
(more of that here and #12736). But that exercise is also not trivial because "higher level transports" like tls and quic do want to see the raw fds. So it might be some time until we cleanup everything.What option would you prefer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eliminating use of the IoHandle::fd() method seems like progress.
Direct creation of FileEvents instead of going through the dispatcher would reduce out ability to mock out FileEvent operations or inject test versions that can easily be marked read/write blocked, unless we add some factory interface similar to the one provided by the dispatchers today.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes potentially we can just have a format/lint checker while we do further cleanups.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and yes maybe also rename
fdDoNotUse()
or something until we fix it all.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works for me! Can we do it after all the PRs are merged to limit impact, i.e., change name and then delete them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup that's fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Added to my todo list :-)