[mojo-edk] Prevent closed port from accepting new messages

[mojo-edk] Prevent closed port from accepting new messages

Previously it was possible for a message to arrive just
before closing a port. In this case OnUserMessage would
grab a ref to the Port object (thus keeping it alive),
ClosePort would close the port (in turn closing any
ports referenced by its message queue), and then it
would be possible for OnUserMessage to continue by
locking the port and enqueueing a (potentially port-
carrying) message onto the queue.

This resolves the issue by making CanAcceptMoreMessages
fail if the port is closed.

Also minor cleanup removing the unused ErasePort method.

TBR=amistry@chromium.org
BUG=

Committed: https://crrev.com/1eb892f358de593644d40d4075cadca59a327f94
Cr-Commit-Position: refs/heads/master@{#393947}

[Ken Rockot(use gerrit already), 2016-05-16 20:58:21]

TBRing for another tiny race fix.

Combined with the broadcast CL, I've verified with a fairly high degree of
confidence that EDK shutdown races are gone. I have a follow-up CL which adds a
regression test to mojo_shell_unittests to exercise racy shutdown behavior.

[Ken Rockot(use gerrit already), 2016-05-16 20:58:23]

The CQ bit was checked by rockot@chromium.org

[commit-bot: I haz the power, 2016-05-16 20:58:55]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1985833002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1985833002/1

[commit-bot: I haz the power, 2016-05-16 22:03:45]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-05-16 22:05:23]

Description was changed from

==========
[mojo-edk] Prevent closed port from accepting new messages

Previously it was possible for a message to arrive just
before closing a port. In this case OnUserMessage would
grab a ref to the Port object (thus keeping it alive),
ClosePort would close the port (in turn closing any
ports referenced by its message queue), and then it
would be possible for OnUserMessage to continue by
locking the port and enqueueing a (potentially port-
carrying) message onto the queue.

This resolves the issue by making CanAcceptMoreMessages
fail if the port is closed.

Also minor cleanup removing the unused ErasePort method.

TBR=amistry@chromium.org
BUG=
==========

to

==========
[mojo-edk] Prevent closed port from accepting new messages

Previously it was possible for a message to arrive just
before closing a port. In this case OnUserMessage would
grab a ref to the Port object (thus keeping it alive),
ClosePort would close the port (in turn closing any
ports referenced by its message queue), and then it
would be possible for OnUserMessage to continue by
locking the port and enqueueing a (potentially port-
carrying) message onto the queue.

This resolves the issue by making CanAcceptMoreMessages
fail if the port is closed.

Also minor cleanup removing the unused ErasePort method.

TBR=amistry@chromium.org
BUG=

Committed: https://crrev.com/1eb892f358de593644d40d4075cadca59a327f94
Cr-Commit-Position: refs/heads/master@{#393947}
==========

[commit-bot: I haz the power, 2016-05-16 22:05:24]

Patchset 1 (id:??) landed as
https://crrev.com/1eb892f358de593644d40d4075cadca59a327f94
Cr-Commit-Position: refs/heads/master@{#393947}

[Anand Mistry (off Chromium), 2016-05-17 04:17:38]

On 2016/05/16 20:58:21, Ken Rockot wrote:
> TBRing for another tiny race fix.
> 
> Combined with the broadcast CL, I've verified with a fairly high degree of
> confidence that EDK shutdown races are gone. I have a follow-up CL which adds
a
> regression test to mojo_shell_unittests to exercise racy shutdown behavior.

FYI, I'll probably end up bringing back ErasePort() as part of my
reduce-ports_lock_contention changes.