[WebSocket] Create Peer on the worker thread.

[WebSocket] Create Peer on the worker thread.

This CL moves the WorkerThreadableWebSocketChannel::Peer construction to
the worker thread from the main thread.
That simplifies the construction and destruction of Peer and removes
#if ENABLE(OILPAN) macros.

BUG=384238
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=178922

[tyoshino (SeeGerritForStatus), 2014-07-24 04:07:11]

Could you please divide this into smaller patches? For example, typedef should
be intended to improve readability, but increasing diff lines much in the most
complicated file to review.

[yhirano, 2014-07-24 04:10:16]

OK, I will do that.

[yhirano, 2014-07-24 05:57:06]

It's ready, PTAL.
This CL depends on https://codereview.chromium.org/410393003/ .

[tyoshino (SeeGerritForStatus), 2014-07-24 08:02:00]

https://codereview.chromium.org/350763007/diff/200001/Source/modules/websocke...
File Source/modules/websockets/WorkerThreadableWebSocketChannel.h (right):

https://codereview.chromium.org/350763007/diff/200001/Source/modules/websocke...
Source/modules/websockets/WorkerThreadableWebSocketChannel.h:171: bool hasPeer()
const { return m_peer; }
I factored out hasTerminatedPeer() as it was not easy to understand that
!m_syncHelper means that the peer has been terminated. Now, it's ok to just use
m_peer in the if-clauses, I think.

[yhirano, 2014-07-24 08:16:22]

https://codereview.chromium.org/350763007/diff/200001/Source/modules/websocke...
File Source/modules/websockets/WorkerThreadableWebSocketChannel.h (right):

https://codereview.chromium.org/350763007/diff/200001/Source/modules/websocke...
Source/modules/websockets/WorkerThreadableWebSocketChannel.h:171: bool hasPeer()
const { return m_peer; }
On 2014/07/24 08:02:00, tyoshino wrote:
> I factored out hasTerminatedPeer() as it was not easy to understand that
> !m_syncHelper means that the peer has been terminated. Now, it's ok to just
use
> m_peer in the if-clauses, I think.

Done.

[tyoshino (SeeGerritForStatus), 2014-07-24 08:20:14]

lg but want to understand that hacks introduced by oilpan guys are really
unrelated once we switch to your new approach. I'll do that tomorrow but haraken
should know much about that. If he l-g-t-m's this, feel free to go ahead to land
this.

[haraken, 2014-07-24 09:22:29]

This is a very nice clean-up! Thanks for doing this. LGTM.

Just to confirm: In oilpan, we have to guarantee that there is no reference from
objects on the main thread to objects on a worker thread when the worker thread
dies. For example, the main thread should not have a Member to the Peer or
SyncHelper object allocated in the worker thread when the worker thread dies. As
far as I see, this is guaranteed. Is my understanding correct?

[yhirano, 2014-07-25 07:18:57]

On 2014/07/24 09:22:29, haraken wrote:
> This is a very nice clean-up! Thanks for doing this. LGTM.
> 
> Just to confirm: In oilpan, we have to guarantee that there is no reference
from
> objects on the main thread to objects on a worker thread when the worker
thread
> dies. For example, the main thread should not have a Member to the Peer or
> SyncHelper object allocated in the worker thread when the worker thread dies.
As
> far as I see, this is guaranteed. Is my understanding correct?

Yes, All resources allocated in the worker thread are released in the worker
thread.

[yhirano, 2014-07-25 07:21:04]

WorkerThreadableWebSocketChannel now uses WebWaitableEvent::wait instead of
waitMultipleObjects because waitMultipleObjects doesn't ensure the corresponding
signal method call is done.
tyoshino@, can you take a look at PS21?

[tyoshino (SeeGerritForStatus), 2014-07-25 08:59:50]

lgtm

[yhirano, 2014-07-25 09:11:21]

The CQ bit was checked by yhirano@chromium.org

[commit-bot: I haz the power, 2014-07-25 09:12:18]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/yhirano@chromium.org/350763007/400001

[commit-bot: I haz the power, 2014-07-25 10:10:44]

Change committed as 178922