Disable fallback path to WebRC platform sockets
Created attachment 449571 [details] Patch
<rdar://problem/87829207>
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.