commit 02090026451f32dfc651f6dd2e384bf2c4f45b69
author Jeremy Roman <jbroman@chromium.org> Fri Jan 11 01:06:47 2019
committer Commit Bot <commit-bot@chromium.org> Fri Jan 11 01:06:47 2019
tree 568642d0cbcaa00be988a0ba446b6493aa42b585
parent 3ae9799de9c6e85984b1b1c4618101bf2702d99e

[Reland] webaudio: Always delete handlers in a non-nestable task on the main thread.

Deleting handlers does considerable non-trivial work that requires the
graph lock. Allowing this to happen during finalization introduces
considerable complexity because it can happen during any GC heap allocation,
including ones that occur while the graph lock is already held.

Instead, when the last reference is dropped, the handler is not deleted
immediately, but a non-nestable task to delete it is enqueued. Since the
task is non-nestable, it will not run while the graph lock is held by the
main thread (and if it is held by another thread, it will block on it).

This slightly extends the lifetime of audio handlers, during which time
it is illegal to take a new reference (and RefCounted checks this in
debug builds). So a flag is set in the destructor (though it could be
sensibly set as early as the ref count reaches zero) that prevents the
handler from adding itself to the tail processing queue if it is already
being destroyed.

The cycle collection layout test is updated to handle the fact that the
handler count does not go to zero immediately on GC, but shortly thereafter.
This has been done by merging with another recently added unit test, which
tests something very similar (a cycle of one element).

The leak detector has been augmented to wait for audio handlers that are
awaiting deletion, if there are any.

Bug: 884059
Change-Id: I818bcdbf87dc3e83359ad7a62aa56547dea2d7a5
Reviewed-on: https://chromium-review.googlesource.com/c/1392109
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Hongchan Choi <hongchan@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#621840}