Signal error on send message failure.

Signal error on send message failure.

Syncronous IPC will deadlock if the message doesn't get sent. Calling
ClosePipeOnError will cause SuicideOnChannelErrorFilter to end the misery.

BUG=338709

[Fredrik Öhrn, 2014-01-28 16:18:44]

Other places that call ProcessOutgoingMessages() will call ClosePipeOnError() if
there is an error, this change follows the same pattern.

An alternative solution would be to check the Send() return value and terminate
in SyncMessageFilter::SendOnIOThread.

[jeremy, 2014-01-28 17:19:39]

The IPC code is really delicate, your change looks fine to me but I'd like to
get a second opinion on this.

agl/brettw/cpu: Could you weigh in please?

[jeremy, 2014-01-28 17:20:29]

Also, do all unit tests pass with this change?
Can you add a unit test that specifically tests the scenario this is trying to
fix?

[Fredrik Öhrn, 2014-01-29 10:37:37]

On 2014/01/28 17:20:29, jeremy wrote:
> Also, do all unit tests pass with this change?

ipc_tests where all green on the trybots.

> Can you add a unit test that specifically tests the scenario this is trying to
> fix?

I'll give it a try.

[Fredrik Öhrn, 2014-01-29 10:41:00]

https://codereview.chromium.org/131513018/diff/1/ipc/ipc_channel_posix.cc
File ipc/ipc_channel_posix.cc (right):

https://codereview.chromium.org/131513018/diff/1/ipc/ipc_channel_posix.cc#new...
ipc/ipc_channel_posix.cc:475: Close();
Yet another alternative is to change Close to ClosePipeOnError here.

Though that would mean ClosePipeOnError gets called twice in some cases, since
several existing code paths also call it when ProcessOutgoingMessages returns
false.

[cpu_(ooo_6.6-7.5), 2014-01-29 19:02:47]

Scott, whatever happened with that other change here?  who was doing it ? hubbe?

[cpu_(ooo_6.6-7.5), 2014-01-29 19:03:26]

found it

https://codereview.chromium.org/30133002/

[Scott Hess - ex-Googler, 2014-01-29 19:13:27]

Yeah, let's defer to the other change, since it seems to have already found a
couple more edge cases.  I'll go ping on the other CL.

[Fredrik Öhrn, 2014-01-30 09:54:30]

On 2014/01/29 19:13:27, shess wrote:
> Yeah, let's defer to the other change, since it seems to have already found a
> couple more edge cases.  I'll go ping on the other CL.

Okely dokely, dropping this review.