Add an implementation of base::SyncSocket::Peek for posix platforms.

Add an implementation of base::SyncSocket::Peek for posix platforms.  Also
update the unit test to test the result.
TEST=ipc_tests/sync_socket_unittest.cc


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

[sehr (please use chromium), 2009-12-05 00:47:12]

I've added what I think should be a reasonable way to get the number of bytes
not read in the socket.

[cpu_(ooo_6.6-7.5), 2009-12-05 02:45:21]

LGTM. In any case wait for evanm feeback since I don't really know unix.

[John Grabowski, 2009-12-05 02:51:26]

More drive-by since I stalk sehr.

1. change the unit test, added by http://codereview.chromium.org/464020, to NOT
be windows-only
2. Add an additional test after the socket_->Receive(static_cast<void*>(buf),
kHelloStringLength) which looks like this:
    EXPECT_FALSE(socket_->Peek()) 
2. Finally, add a 3rd unit test which does EXPECT_FALSE(socket_->Peek()) on a
newly created socket.

If all that passes the try servers it should be clear how this looks.

[cpu_(ooo_6.6-7.5), 2009-12-05 02:59:57]

Forgot to say that you want to enable the unit test in this CL as well.

On 2009/12/05 02:45:21, cpu wrote:
> LGTM. In any case wait for evanm feeback since I don't really know unix.

[sehr (please use chromium), 2009-12-05 06:44:18]

On 2009/12/05 02:59:57, cpu wrote:
> Forgot to say that you want to enable the unit test in this CL as well.
> 
> On 2009/12/05 02:45:21, cpu wrote:
> > LGTM. In any case wait for evanm feeback since I don't really know unix.

Unittest changed in accordance with JRG's suggestions.  Please have another
look.

[sehr (please use chromium), 2009-12-05 16:46:50]

On 2009/12/05 06:44:18, sehr wrote:
> On 2009/12/05 02:59:57, cpu wrote:
> > Forgot to say that you want to enable the unit test in this CL as well.
> > 
> > On 2009/12/05 02:45:21, cpu wrote:
> > > LGTM. In any case wait for evanm feeback since I don't really know unix.
> 
> Unittest changed in accordance with JRG's suggestions.  Please have another
> look.

FWIW, I've looked into the Linux fail and it's due to some flaky UI tests. 
Since this class isn't yet used other than by an ipc_tests unittest, I don't
think that failure is real.

[John Grabowski, 2009-12-05 17:36:52]

LGTM from the stalker

[Evan Martin, 2009-12-06 01:45:22]

seems ok to me

http://codereview.chromium.org/468023/diff/3002/3004
File ipc/sync_socket_unittest.cc (right):

http://codereview.chromium.org/468023/diff/3002/3004#newcode201
ipc/sync_socket_unittest.cc:201: EXPECT_NE(msg,
reinterpret_cast<IPC::Message*>(NULL));
Off-topic, but I think if "new" returns NULL you've got more major problems than
something a unittest can check for...

[sehr (please use chromium), 2009-12-06 19:40:54]

On 2009/12/06 01:45:22, Evan Martin wrote:
> seems ok to me
> 
> http://codereview.chromium.org/468023/diff/3002/3004
> File ipc/sync_socket_unittest.cc (right):
> 
> http://codereview.chromium.org/468023/diff/3002/3004#newcode201
> ipc/sync_socket_unittest.cc:201: EXPECT_NE(msg,
> reinterpret_cast<IPC::Message*>(NULL));
> Off-topic, but I think if "new" returns NULL you've got more major problems
than
> something a unittest can check for...

I agree that out of memory is a much bigger problem.  Is it preferred to ASSERT
or just not check?

[Evan Martin, 2009-12-06 20:55:39]

On 2009/12/06 19:40:54, sehr wrote:
> I agree that out of memory is a much bigger problem.  Is it preferred to
ASSERT
> or just not check?

I'd just not check (we set things up so that we crash immediately when
allocations fail).