Bug 57718 – didFailToSendSyncMessage should not be a client call

• Component: WebKit2
• Status: RESOLVED DUPLICATE

[Alexey Proskuryakov]

didFailToSendSyncMessage exists to guarantee that a sync call in a client process never returns null, which is important because client code is unlikely to handle such a return properly.

But it's a client call, and client pointer can be null, so the code has become nonsensical after having been introduced.

[Alexey Proskuryakov]

Created attachment 87995 [details]
proposed patch

[Eric Seidel (no email)]

Comment on attachment 87995 [details]
proposed patch

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

> Source/WebKit2/Platform/CoreIPC/Connection.cpp:422
> +        exit(0);

Funny that this error condition exits 0.  I guess that's to mean that the process intended to end itself?

[Alexey Proskuryakov]

Comment on attachment 87995 [details]
proposed patch

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

>> Source/WebKit2/Platform/CoreIPC/Connection.cpp:422

> 
> Funny that this error condition exits 0.  I guess that's to mean that the process intended to end itself?

This is a fatal condition (most likely, the server process has exited already) - but if we return a super rare null result, we can crash instead if cleanly exiting a moment later.

[Anders Carlsson]

We don't want all client connections to do this, so I think this should be a callback function on the connection instead.

[Alexey Proskuryakov]

<rdar://problem/9251669>

[Alexey Proskuryakov]

Anders landed this patch in another bug, with one difference being that we only set the flag on Web to UI process connection.

*** This bug has been marked as a duplicate of bug 58923 ***