AwakableList: For persistent awakables, make Add() call Awake() with reason INITIALIZE.

AwakableList: For persistent awakables, make Add() call Awake() with reason INITIALIZE.

This will let WaitSetDispatcher actually properly track the states of
the things it's tracking. (This is not done in this change.)

One may wonder why this is desirable -- why can't the caller of Add()
just check/record the state before calling Add()? The problem has to do
with lock order. E.g., WaitSetDispatcher can't call other dispatchers'
methods under its mutex. In particular, it can't call
Dispatcher::AddAwakable() nor GetHandleSignalsState(). So getting the
initial state and arranging to get updates would always necessarily be
subject to a race condition.

R=vardhan@google.com
BUG=#350

Committed: https://chromium.googlesource.com/external/mojo/+/68d8506dfe9ea43191ea430d9377a65e5063300e

[vardhan, 2016-06-23 18:13:54]

lgtm

[viettrungluu, 2016-06-23 20:01:43]

Description was changed from

==========
AwakableList: For persistent awakables, make Add() call Awake() with reason
INITIALIZE.

This will let WaitSetDispatcher actually properly track the states of
the things it's tracking. (This is not done in this change.)

One may wonder why this is desirable -- why can't the caller of Add()
just check/record the state before calling Add()? The problem has to do
with lock order. E.g., WaitSetDispatcher can't call other dispatchers'
methods under its mutex. In particular, it can't call
Dispatcher::AddAwakable() nor GetHandleSignalsState(). So getting the
initial state and arranging to get updates would always necessarily be
subject to a race condition.

R=vardhan@google.com
BUG=#350
==========

to

==========
AwakableList: For persistent awakables, make Add() call Awake() with reason
INITIALIZE.

This will let WaitSetDispatcher actually properly track the states of
the things it's tracking. (This is not done in this change.)

One may wonder why this is desirable -- why can't the caller of Add()
just check/record the state before calling Add()? The problem has to do
with lock order. E.g., WaitSetDispatcher can't call other dispatchers'
methods under its mutex. In particular, it can't call
Dispatcher::AddAwakable() nor GetHandleSignalsState(). So getting the
initial state and arranging to get updates would always necessarily be
subject to a race condition.

R=vardhan@google.com
BUG=#350

Committed:
https://chromium.googlesource.com/external/mojo/+/68d8506dfe9ea43191ea430d937...
==========

[viettrungluu, 2016-06-23 20:01:45]

Committed patchset #1 (id:1) manually as
68d8506dfe9ea43191ea430d9377a65e5063300e (presubmit successful).