Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2880923002:
Support epoll in PhysicalSocketServer. (Closed)
DescriptionSupport epoll in PhysicalSocketServer.
Only will be used if WEBRTC_POSIX and WEBRTC_LINUX are both defined and
"epoll_create" doesn't return an error. Otherwise the default "select"-based
IO loop will be used.
BUG=webrtc:7585
Review-Url: https://codereview.webrtc.org/2880923002
Cr-Commit-Position: refs/heads/master@{#18359}
Committed: https://chromium.googlesource.com/external/webrtc/+/de4db1179884d3948a1808f50f6bee9c3d4f3bd7
Patch Set 1 #Patch Set 2 : Fix for undefined EPOLLRDHUP. #
Total comments: 13
Patch Set 3 : Feedback from Taylor. #
Total comments: 10
Patch Set 4 : More feedback. #
Total comments: 1
Patch Set 5 : Renamed methods, added comment. #
Total comments: 2
Patch Set 6 : Fixed typo. #
Total comments: 2
Patch Set 7 : Defer adding/removing of dispatchers while processing events. #
Total comments: 6
Patch Set 8 : More feedback from Taylor, also use dispatcher set on Windows." #Patch Set 9 : AddRemovePendingDispatchers is also required on Windows now. #Patch Set 10 : Win: Prevent updates to dispatcher in loop before waiting. #
Depends on Patchset: Messages
Total messages: 32 (10 generated)
jbauch@webrtc.org changed reviewers: + deadbeef@webrtc.org
Ptal I'm not sure how this should be tested. Add a method to force use of epoll/select and run all from physicalsocketserver_unittest.cc with both variants on WEBRTC_LINUX?
Looks pretty good, just some minor comments. For testing, I'd say the fact that the tests run on a range of OSes gives adequate coverage. If this ends up being a problem we can revisit it later. https://codereview.webrtc.org/2880923002/diff/20001/webrtc/base/physicalsocke... File webrtc/base/physicalsocketserver.cc (right): https://codereview.webrtc.org/2880923002/diff/20001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:145: SetEnabledEvents(DE_READ | DE_WRITE); nit: The "SetEnabledEvents" etc. change seems like it could be in an independent CL https://codereview.webrtc.org/2880923002/diff/20001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:841: #if defined(WEBRTC_LINUX) nit: It may be cleaner to do "#ifdef WEBRTC_LINUX #define USE_EPOLL" at the top of this file, then these could be "#ifdef USE_EPOLL" which is more readable. https://codereview.webrtc.org/2880923002/diff/20001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:877: enabled_events_stack_.push_back(enabled_events_); Will the stack ever have a size > 1? If so, can you leave a comment explaining how? If not, I think this code could be simplified somewhat. https://codereview.webrtc.org/2880923002/diff/20001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:1250: epoll_fd_ = INVALID_SOCKET; Could you leave a comment mentioning that the code will fall back to select() if epoll_create() failed? https://codereview.webrtc.org/2880923002/diff/20001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:1327: #else Is there a reason the set can't be used on Windows? https://codereview.webrtc.org/2880923002/diff/20001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:1373: void PhysicalSocketServer::Update(Dispatcher *pdispatcher) { It seems like the code would be more readable if there was an "#ifdef" at the call site, which called a method named "UpdateEpoll" directly.
Thanks for your review, all comments addressed. https://codereview.webrtc.org/2880923002/diff/20001/webrtc/base/physicalsocke... File webrtc/base/physicalsocketserver.cc (right): https://codereview.webrtc.org/2880923002/diff/20001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:145: SetEnabledEvents(DE_READ | DE_WRITE); On 2017/05/17 07:20:16, Taylor Brandstetter wrote: > nit: The "SetEnabledEvents" etc. change seems like it could be in an independent > CL Moved to https://codereview.webrtc.org/2893723002/ https://codereview.webrtc.org/2880923002/diff/20001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:841: #if defined(WEBRTC_LINUX) On 2017/05/17 07:20:16, Taylor Brandstetter wrote: > nit: It may be cleaner to do "#ifdef WEBRTC_LINUX #define USE_EPOLL" at the top > of this file, then these could be "#ifdef USE_EPOLL" which is more readable. Done (named it "WEBRTC_USE_EPOLL"). https://codereview.webrtc.org/2880923002/diff/20001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:877: enabled_events_stack_.push_back(enabled_events_); On 2017/05/17 07:20:16, Taylor Brandstetter wrote: > Will the stack ever have a size > 1? If so, can you leave a comment explaining > how? If not, I think this code could be simplified somewhat. Currently it will only be one element. I'll change it and rename to "SaveEnabledEvents" / "RestoreEnabledEvents". https://codereview.webrtc.org/2880923002/diff/20001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:1250: epoll_fd_ = INVALID_SOCKET; On 2017/05/17 07:20:16, Taylor Brandstetter wrote: > Could you leave a comment mentioning that the code will fall back to select() if > epoll_create() failed? Done. https://codereview.webrtc.org/2880923002/diff/20001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:1327: #else On 2017/05/17 07:20:16, Taylor Brandstetter wrote: > Is there a reason the set can't be used on Windows? The Windows code has some special handling to invalidate iterators used in "Wait" below when removing dispatchers from the PSS. For this it needs the position of the removed dispatcher, so we can't use a set there. I didn't take a deeper look and in any case if something is changed there, I think it should be done in a separate CL. https://codereview.webrtc.org/2880923002/diff/20001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:1373: void PhysicalSocketServer::Update(Dispatcher *pdispatcher) { On 2017/05/17 07:20:16, Taylor Brandstetter wrote: > It seems like the code would be more readable if there was an "#ifdef" at the > call site, which called a method named "UpdateEpoll" directly. The call site for this is the SocketDispatcher. I wanted to hide the "epoll" implementation detail of the PSS and keep the public method names consistent. Already available are "Add" and "Remove" with "Update" being added in this CL. I you really think it would be more readable to name this "UpdateEpoll" and call that from the SocketDispatcher, I can change it.
deadbeef@webrtc.org changed reviewers: + tommi@webrtc.org
A broader question about this CL (which I should have asked earlier, sorry): what are the reasons for using epoll as opposed to poll? I haven't used either before, but from what I've gathered, epoll scales better for a very large number of descriptors. But can be slower for a small number of descriptors, and also doesn't perform well if "epoll_ctl" needs to be called frequently (due to new sockets being added/removed, or the "EPOLLIN/EPOLLOUT" events changing). So, which makes more sense in the WebRTC context? Would poll() make more sense as a default? Adding Tommi in case he has any thoughts on this. He seemed to know more than me about poll/epoll from an earlier email thread. https://codereview.webrtc.org/2880923002/diff/20001/webrtc/base/physicalsocke... File webrtc/base/physicalsocketserver.cc (right): https://codereview.webrtc.org/2880923002/diff/20001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:1373: void PhysicalSocketServer::Update(Dispatcher *pdispatcher) { On 2017/05/17 21:17:02, joachim wrote: > On 2017/05/17 07:20:16, Taylor Brandstetter wrote: > > It seems like the code would be more readable if there was an "#ifdef" at the > > call site, which called a method named "UpdateEpoll" directly. > > The call site for this is the SocketDispatcher. I wanted to hide the "epoll" > implementation detail of the PSS and keep the public method names consistent. > > Already available are "Add" and "Remove" with "Update" being added in this CL. I > you really think it would be more readable to name this "UpdateEpoll" and call > that from the SocketDispatcher, I can change it. I see now; in that case this is fine. https://codereview.webrtc.org/2880923002/diff/40001/webrtc/base/physicalsocke... File webrtc/base/physicalsocketserver.cc (right): https://codereview.webrtc.org/2880923002/diff/40001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:804: RestoreEnabledEvents(); This name isn't very intuitive; it sounds like it would do "enabled_events_ = saved_enabled_events_". Better names may be "StartBatchedEventUpdates" and "FinishBatchedEventUpdates", or something along those lines. Though in my opinion, this is a little overkill in the first place. This method could just do: uint8_t events_to_disable = 0; if ((ff & DE_CONNECT) != 0) { events_to_disable |= DE_CONNECT; SignalConnectEvent(this); } /* ... */ if ((ff & DE_CLOSE) != 0) { events_to_disable = 0xff; SignalCloseEvent(this, err); } DisableEvents(events_to_disable); That would avoid needing an extra member variable and two methods. https://codereview.webrtc.org/2880923002/diff/40001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:825: if (enabled_events() != old_events && saved_enabled_events_ == -1) { Since DE_READ and DE_ACCEPT both map to EPOLLIN: suppose the enabled events go from "DE_ACCEPT" to "DE_ACCEPT | DE_READ". This would result in epoll_ctl being called a second time with the same arguments, right? Should this function use a condition like this instead, to avoid redundant system calls? if (EpollEvents(enabled_events()) != EpollEvents(old_events) ...)
zhaoyanfeng@google.com changed reviewers: + zhaoyanfeng@google.com
https://codereview.webrtc.org/2880923002/diff/40001/webrtc/base/physicalsocke... File webrtc/base/physicalsocketserver.cc (right): https://codereview.webrtc.org/2880923002/diff/40001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:1336: } If process_io == false, still use select? That seems crash when fd goes above 1024.
See below for some feedback, I will upload a new version later today. https://codereview.webrtc.org/2880923002/diff/40001/webrtc/base/physicalsocke... File webrtc/base/physicalsocketserver.cc (right): https://codereview.webrtc.org/2880923002/diff/40001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:804: RestoreEnabledEvents(); On 2017/05/17 23:19:02, Taylor Brandstetter wrote: > This name isn't very intuitive; it sounds like it would do "enabled_events_ = > saved_enabled_events_". Better names may be "StartBatchedEventUpdates" and > "FinishBatchedEventUpdates", or something along those lines. > > Though in my opinion, this is a little overkill in the first place. This method > could just do: > > uint8_t events_to_disable = 0; > if ((ff & DE_CONNECT) != 0) { > events_to_disable |= DE_CONNECT; > SignalConnectEvent(this); > } > /* ... */ > if ((ff & DE_CLOSE) != 0) { > events_to_disable = 0xff; > SignalCloseEvent(this, err); > } > DisableEvents(events_to_disable); > > That would avoid needing an extra member variable and two methods. Keeping a bitmask of events to disable won't work, because the signal handlers might re-enable some events. These don't get updated in "events_to_disable" and would wrongly be disabled at the end. https://codereview.webrtc.org/2880923002/diff/40001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:825: if (enabled_events() != old_events && saved_enabled_events_ == -1) { On 2017/05/17 23:19:02, Taylor Brandstetter wrote: > Since DE_READ and DE_ACCEPT both map to EPOLLIN: suppose the enabled events go > from "DE_ACCEPT" to "DE_ACCEPT | DE_READ". This would result in epoll_ctl being > called a second time with the same arguments, right? > > Should this function use a condition like this instead, to avoid redundant > system calls? > > if (EpollEvents(enabled_events()) != EpollEvents(old_events) ...) Right, thanks for spotting. https://codereview.webrtc.org/2880923002/diff/40001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:1336: } On 2017/05/18 07:46:17, zhaoyanfeng wrote: > If process_io == false, still use select? > That seems crash when fd goes above 1024. The wakeup dispatcher is created early during construction of the PSS, so its fd should be below 1024. But you're right, to be on the safe side I should keep a separate epoll descriptor for it.
https://codereview.webrtc.org/2880923002/diff/40001/webrtc/base/physicalsocke... File webrtc/base/physicalsocketserver.cc (right): https://codereview.webrtc.org/2880923002/diff/40001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:1336: } On 2017/05/18 12:41:49, joachim wrote: > On 2017/05/18 07:46:17, zhaoyanfeng wrote: > > If process_io == false, still use select? > > That seems crash when fd goes above 1024. > > The wakeup dispatcher is created early during construction of the PSS, so its fd > should be below 1024. But you're right, to be on the safe side I should keep a > separate epoll descriptor for it. I have tested it in our server but failed, our server contains many modules, WebRTC is one of them, so the fd maybe above 1024 when the wakeup dispatcher is created. We'd better use epoll here completely. Thanks for fixing.
I updated the code to no longer use "select" for waiting on the signal dispatcher. Also I refactored some common code to a separate function. Ptal https://codereview.webrtc.org/2880923002/diff/40001/webrtc/base/physicalsocke... File webrtc/base/physicalsocketserver.cc (right): https://codereview.webrtc.org/2880923002/diff/40001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:1336: } On 2017/05/18 14:08:37, zhaoyanfeng wrote: > On 2017/05/18 12:41:49, joachim wrote: > > On 2017/05/18 07:46:17, zhaoyanfeng wrote: > > > If process_io == false, still use select? > > > That seems crash when fd goes above 1024. > > > > The wakeup dispatcher is created early during construction of the PSS, so its > fd > > should be below 1024. But you're right, to be on the safe side I should keep a > > separate epoll descriptor for it. > > I have tested it in our server but failed, our server contains many modules, > WebRTC is one of them, so the fd maybe above 1024 when the wakeup dispatcher is > created. > We'd better use epoll here completely. > Thanks for fixing. > I changed it now to use "poll" to wait for the signaling dispatcher instead of maintaining a separate epoll dispatcher.
lgtm, with some nits about comments/naming. https://codereview.webrtc.org/2880923002/diff/40001/webrtc/base/physicalsocke... File webrtc/base/physicalsocketserver.cc (right): https://codereview.webrtc.org/2880923002/diff/40001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:804: RestoreEnabledEvents(); On 2017/05/18 12:41:49, joachim wrote: > On 2017/05/17 23:19:02, Taylor Brandstetter wrote: > > This name isn't very intuitive; it sounds like it would do "enabled_events_ = > > saved_enabled_events_". Better names may be "StartBatchedEventUpdates" and > > "FinishBatchedEventUpdates", or something along those lines. > > > > Though in my opinion, this is a little overkill in the first place. This > method > > could just do: > > > > uint8_t events_to_disable = 0; > > if ((ff & DE_CONNECT) != 0) { > > events_to_disable |= DE_CONNECT; > > SignalConnectEvent(this); > > } > > /* ... */ > > if ((ff & DE_CLOSE) != 0) { > > events_to_disable = 0xff; > > SignalCloseEvent(this, err); > > } > > DisableEvents(events_to_disable); > > > > That would avoid needing an extra member variable and two methods. > > Keeping a bitmask of events to disable won't work, because the signal handlers > might re-enable some events. These don't get updated in "events_to_disable" and > would wrongly be disabled at the end. Ah, that's what I was missing. Can you mention it in a comment? https://codereview.webrtc.org/2880923002/diff/60001/webrtc/base/physicalsocke... File webrtc/base/physicalsocketserver.cc (right): https://codereview.webrtc.org/2880923002/diff/60001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:835: void SocketDispatcher::RestoreEnabledEvents() { I still think the names "Save/Restore" give the wrong impression. Can you think of different names, or at least document the behavior in a comment in the header file?
I renamed the methods and added a comment, ptal. Tommi, ping (Taylor added you in case you had some thoughts on this)? zhaoyanfeng, could you please try this in your server and see if it fixes the issues you were seeing? https://codereview.webrtc.org/2880923002/diff/40001/webrtc/base/physicalsocke... File webrtc/base/physicalsocketserver.cc (right): https://codereview.webrtc.org/2880923002/diff/40001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:804: RestoreEnabledEvents(); On 2017/05/18 21:59:56, Taylor Brandstetter wrote: > On 2017/05/18 12:41:49, joachim wrote: > > On 2017/05/17 23:19:02, Taylor Brandstetter wrote: > > > This name isn't very intuitive; it sounds like it would do "enabled_events_ > = > > > saved_enabled_events_". Better names may be "StartBatchedEventUpdates" and > > > "FinishBatchedEventUpdates", or something along those lines. > > > > > > Though in my opinion, this is a little overkill in the first place. This > > method > > > could just do: > > > > > > uint8_t events_to_disable = 0; > > > if ((ff & DE_CONNECT) != 0) { > > > events_to_disable |= DE_CONNECT; > > > SignalConnectEvent(this); > > > } > > > /* ... */ > > > if ((ff & DE_CLOSE) != 0) { > > > events_to_disable = 0xff; > > > SignalCloseEvent(this, err); > > > } > > > DisableEvents(events_to_disable); > > > > > > That would avoid needing an extra member variable and two methods. > > > > Keeping a bitmask of events to disable won't work, because the signal handlers > > might re-enable some events. These don't get updated in "events_to_disable" > and > > would wrongly be disabled at the end. > > Ah, that's what I was missing. Can you mention it in a comment? Done.
lgtm again. https://codereview.webrtc.org/2880923002/diff/80001/webrtc/base/physicalsocke... File webrtc/base/physicalsocketserver.cc (right): https://codereview.webrtc.org/2880923002/diff/80001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:787: // would not not be updated with the events enabled by the signal handlers. nit: "not not"
https://codereview.webrtc.org/2880923002/diff/80001/webrtc/base/physicalsocke... File webrtc/base/physicalsocketserver.cc (right): https://codereview.webrtc.org/2880923002/diff/80001/webrtc/base/physicalsocke... webrtc/base/physicalsocketserver.cc:787: // would not not be updated with the events enabled by the signal handlers. On 2017/05/19 20:52:43, Taylor Brandstetter wrote: > nit: "not not" Whoops, thanks.
Lgtm, thanks for doing this
The CQ bit was checked by jbauch@webrtc.org
The patchset sent to the CQ was uploaded after l-g-t-m from deadbeef@webrtc.org Link to the patchset: https://codereview.webrtc.org/2880923002/#ps100001 (title: "Fixed typo.")
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: mac_asan on master.tryserver.webrtc (JOB_FAILED, http://build.chromium.org/p/tryserver.webrtc/builders/mac_asan/builds/24912)
https://codereview.webrtc.org/2880923002/diff/100001/webrtc/base/physicalsock... File webrtc/base/physicalsocketserver.cc (right): https://codereview.webrtc.org/2880923002/diff/100001/webrtc/base/physicalsock... webrtc/base/physicalsocketserver.cc:1494: for (Dispatcher *pdispatcher : dispatchers_) { I think changing this to a for-each style loop is what broke mac_asan, since the list can be modified while it's being iterated.
Ptal https://codereview.webrtc.org/2880923002/diff/100001/webrtc/base/physicalsock... File webrtc/base/physicalsocketserver.cc (right): https://codereview.webrtc.org/2880923002/diff/100001/webrtc/base/physicalsock... webrtc/base/physicalsocketserver.cc:1494: for (Dispatcher *pdispatcher : dispatchers_) { On 2017/05/25 16:46:26, Taylor Brandstetter wrote: > I think changing this to a for-each style loop is what broke mac_asan, since the > list can be modified while it's being iterated. Yes, also saw this. I updated the code to defer adding/removing of dispatchers while the events are being processed. Something similar could maybe also be used for the Windows code to get rid of the special iterator invalidating when removing dispatchers and also use a std::set there. I'll take a look at this in a separate CL.
https://codereview.webrtc.org/2880923002/diff/120001/webrtc/base/physicalsock... File webrtc/base/physicalsocketserver.cc (right): https://codereview.webrtc.org/2880923002/diff/120001/webrtc/base/physicalsock... webrtc/base/physicalsocketserver.cc:1434: for (Dispatcher *pdispatcher : pending_add_dispatchers_) { Should be "Dispatcher* pdispatcher"; can you run "git cl format"? https://codereview.webrtc.org/2880923002/diff/120001/webrtc/base/physicalsock... webrtc/base/physicalsocketserver.cc:1555: // event were handled above. "event" -> "events" https://codereview.webrtc.org/2880923002/diff/120001/webrtc/base/physicalsock... File webrtc/base/physicalsocketserver.h (right): https://codereview.webrtc.org/2880923002/diff/120001/webrtc/base/physicalsock... webrtc/base/physicalsocketserver.h:134: #endif This code is going to confusing to maintain if |dispatchers_| can be either a set or a list, and different strategies are used for handling modifications while iterating. Would it be easier now to switch to using a set everywhere, using "pending_remove_dispatchers_" for the Windows code as well? If not, can you leave a comment explaining why not, and describing what would need to be done?
All changed, ptal. https://codereview.webrtc.org/2880923002/diff/120001/webrtc/base/physicalsock... File webrtc/base/physicalsocketserver.cc (right): https://codereview.webrtc.org/2880923002/diff/120001/webrtc/base/physicalsock... webrtc/base/physicalsocketserver.cc:1434: for (Dispatcher *pdispatcher : pending_add_dispatchers_) { On 2017/05/30 22:05:49, Taylor Brandstetter wrote: > Should be "Dispatcher* pdispatcher"; can you run "git cl format"? Done. https://codereview.webrtc.org/2880923002/diff/120001/webrtc/base/physicalsock... webrtc/base/physicalsocketserver.cc:1555: // event were handled above. On 2017/05/30 22:05:49, Taylor Brandstetter wrote: > "event" -> "events" Done. https://codereview.webrtc.org/2880923002/diff/120001/webrtc/base/physicalsock... File webrtc/base/physicalsocketserver.h (right): https://codereview.webrtc.org/2880923002/diff/120001/webrtc/base/physicalsock... webrtc/base/physicalsocketserver.h:134: #endif On 2017/05/30 22:05:50, Taylor Brandstetter wrote: > This code is going to confusing to maintain if |dispatchers_| can be either a > set or a list, and different strategies are used for handling modifications > while iterating. Would it be easier now to switch to using a set everywhere, > using "pending_remove_dispatchers_" for the Windows code as well? If not, can > you leave a comment explaining why not, and describing what would need to be > done? I agree. As commented before, I wanted to switch the Windows code to use the same set in a separate CL, but did it in this now.
lgtm
The CQ bit was checked by jbauch@webrtc.org
The patchset sent to the CQ was uploaded after l-g-t-m from tommi@webrtc.org Link to the patchset: https://codereview.webrtc.org/2880923002/#ps180001 (title: "Win: Prevent updates to dispatcher in loop before waiting.")
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...
CQ is committing da patch.
Bot data: {"patchset_id": 180001, "attempt_start_ts": 1496260202904630,
"parent_rev": "0cdb0ff0d69744b829249fd9ad1b373a1ebb2e4f", "commit_rev":
"de4db1179884d3948a1808f50f6bee9c3d4f3bd7"}
Message was sent while issue was closed.
Description was changed from ========== Support epoll in PhysicalSocketServer. Only will be used if WEBRTC_POSIX and WEBRTC_LINUX are both defined and "epoll_create" doesn't return an error. Otherwise the default "select"-based IO loop will be used. BUG=webrtc:7585 ========== to ========== Support epoll in PhysicalSocketServer. Only will be used if WEBRTC_POSIX and WEBRTC_LINUX are both defined and "epoll_create" doesn't return an error. Otherwise the default "select"-based IO loop will be used. BUG=webrtc:7585 Review-Url: https://codereview.webrtc.org/2880923002 Cr-Commit-Position: refs/heads/master@{#18359} Committed: https://chromium.googlesource.com/external/webrtc/+/de4db1179884d3948a1808f50... ==========
Message was sent while issue was closed.
Committed patchset #10 (id:180001) as https://chromium.googlesource.com/external/webrtc/+/de4db1179884d3948a1808f50... |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
