[webkit-reviews] review denied: [Bug 169930] Make WebSockets work in network process : [Attachment 305099] Patch

[bugzilla-daemon at webkit.org]

Brady Eidson <beidson at apple.com> has denied Alex Christensen
<achristensen at apple.com>'s request for review:
Bug 169930: Make WebSockets work in network process
https://bugs.webkit.org/show_bug.cgi?id=169930

Attachment 305099: Patch

https://bugs.webkit.org/attachment.cgi?id=305099&action=review




--- Comment #6 from Brady Eidson <beidson at apple.com> ---
Comment on attachment 305099
  --> https://bugs.webkit.org/attachment.cgi?id=305099
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=305099&action=review

> Source/WebKit2/WebProcess/Network/WebSocketStream.cpp:57
> +void WebSocketStream::networkProcessCrashed()

You handle the WebProcess side of "networking process did crash", but you don't
handle the NetworkProcess side of "web process did crash"

Additionally, I wonder if we can API test both of those.

> Source/WebKit2/WebProcess/Network/WebSocketStream.cpp:86
> +   
WebProcess::singleton().networkConnection().connection().send(Messages::Network
ConnectionToWebProcess::DestroySocketStream(m_identifier), 0);

Can we send the DestroySocketStream any sooner than the WebSocketStream d'tor?

My concern would be that some other arbitrary code (JS, Ref<>/RefPtr<>, etc)
can keep the WebSocketStream alive indefinitely even after it becomes an inert
object and we could clean up its resources in the Networking process.

> Source/WebKit2/WebProcess/Network/WebSocketStream.cpp:119
> +    send(Messages::NetworkSocketStream::Close());

e.g. - Why is this "Close" not a "DestroySocketStream", and we just make sure
platformClose is always called before the d'tor?