Inconsistencies with "control thread state"

[karlt]

The state attribute says "its value is identical to control thread state."

Another overview also says "control thread state is the equivalent of state".

However, these two states are updated at different times in the close(), suspend(), and resume() processes.

Also, even if a constructed AudioContext is allowed to start, the control thread state remains suspended until resume() is called. This is OK because the control thread state is only ever compared with closed, so suspended and running values are equivalent.

Proposal: remove everything that says that control thread state and state are related and replace "control thread state" with a "closed flag".

[rtoy]

Teleconf:

This makes sense. We'll look through and make the necessary changes.

However, I personally prefer to keep control thread state in case we find at some later date that we do need to peek at the other values. If that happens, we'll just have to undo this change anyway.

[rtoy]

Se also #72, which hasn't been resolved yet, but it might change how control thread state is referenced.