Summary: | Disable fallback path to WebRTC platform sockets | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | youenn fablet <youennf> | ||||
Component: | WebRTC | Assignee: | youenn fablet <youennf> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | eric.carlson, ews-watchlist, ggaren, webkit-bug-importer, youennf | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | WebKit Nightly Build | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
youenn fablet
2022-01-20 06:47:07 PST
Created attachment 449571 [details]
Patch
Committed r288296 (246218@main): <https://commits.webkit.org/246218@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 449571 [details]. Comment on attachment 449571 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=449571&action=review > Source/WebKit/ChangeLog:10 > + We should not fallback to the legacy WebRTC socket code path in Cocoa ports. > + Instead, if we cannot create the corresponding sockets (in case of ssltcp candidates for instance), > + we mark the socket as closed. What's the expected outcome when we mark the socket as closed, and why is it an improvement? (In reply to Geoffrey Garen from comment #4) > Comment on attachment 449571 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=449571&action=review > > > Source/WebKit/ChangeLog:10 > > + We should not fallback to the legacy WebRTC socket code path in Cocoa ports. > > + Instead, if we cannot create the corresponding sockets (in case of ssltcp candidates for instance), > > + we mark the socket as closed. > > What's the expected outcome when we mark the socket as closed, and why is it > an improvement? The improvement is mostly to not go on the legacy code path (so we return early whenever m_platformTCPSocketsEnabled is true). Closing the socket is notifying the WebProcess that this socket cannot be used, which is better for memory management. |