AudioStreamCallback design prone to race conditions

[philburk]

The AudioStreamCallback contains a raw AudioStream pointer, which it passes to its callback methods.

If the onErrorBeforeClose() method has a delay, then there can be a large a window where the AudioStream could be closed and deleted by another thread, perhaps by user interaction. The AudioStreamCallback will then crash when it tries to close the stream.

The delete must not occur while the AudioStreamCallback is active. This is complicated by the fact that the AudioStreamCallback launches a separate thread to do the closing.

Perhaps the OboeStream destructor could join() the closing thread in the AudioStreamCallback.

Or a shared pointer could be used to defer the actual deletion. And that shared pointer could be passed to the AudioStreamCallback.

[philburk]

A crash can be reproduced by adding:

usleep(2000 * 1000);

at the end of OboeStreamCallbackProxy::onErrorBeforeClose() in OboeTester,
then running TEST DISCONNECT.