Add a base class for objects that want to filter messages on the UI thread. ...

Add a base class for objects that want to filter messages on the IO thread.  I'll switch the filters to it in future separate changes.

I've also taken out the special case for an initial filter from the IPC classes.  The reason it existed was that there was a race condition of some messages not being filtered if a filter is added after construction but before launching the peer process.  Taking it out allows us to add more than one filter and makes things a little cleaner.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=68043

[Matt Perry, 2010-12-02 01:15:22]

LGTM, though BrowserIOMessageFilter looks unused. I guess it will be used in a
future CL?

[jam, 2010-12-02 01:16:26]

On 2010/12/02 01:15:22, Matt Perry wrote:
> LGTM, though BrowserIOMessageFilter looks unused. I guess it will be used in a
> future CL?

exactly.  I wanted to do them each separately, since looking through most of
these filters I see other stuff I want to cleanup.

[jam, 2010-12-02 17:51:35]

hey Matt, please have another look.  My previous attempt at solving the race
condition wasn't correct.  I've taken a new stab at it that should be race-proof
and also doesn't use locks when a message arrives.

[Matt Perry, 2010-12-02 19:00:39]

http://codereview.chromium.org/5513001/diff/22002/ipc/ipc_channel_proxy.cc
File ipc/ipc_channel_proxy.cc (right):

http://codereview.chromium.org/5513001/diff/22002/ipc/ipc_channel_proxy.cc#ne...
ipc/ipc_channel_proxy.cc:317: context_.get(), &Context::OnChannelOpened));
Couldn't this cause OnChannelOpened to run, then OnChannelConnected, all before
any subsequent calls to AddFiler? I think you still need to call this from a
PostTask to the listener thread.

[jam, 2010-12-02 19:08:52]

http://codereview.chromium.org/5513001/diff/22002/ipc/ipc_channel_proxy.cc
File ipc/ipc_channel_proxy.cc (right):

http://codereview.chromium.org/5513001/diff/22002/ipc/ipc_channel_proxy.cc#ne...
ipc/ipc_channel_proxy.cc:317: context_.get(), &Context::OnChannelOpened));
On 2010/12/02 19:00:39, Matt Perry wrote:
> Couldn't this cause OnChannelOpened to run, then OnChannelConnected, all
before
> any subsequent calls to AddFiler?

That's fine, since OnAddFilter will call OnChannelConnected if a filter is added
after the channel is connected.

> I think you still need to call this from a
> PostTask to the listener thread.

this can result in the channel not working (i had tried this before).  the
problem is that if you create a channel and call send() on it, you don't expect
that you have to run the current message loop in between.

[Matt Perry, 2010-12-02 19:14:51]

LGTM, per discussion in person (summary: if child process is launched after
AddFilter calls, we are guaranteed not to miss messages)