Bug 1598413 Comment 1 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
Several racing issues:
1. If `cubeb_stream_start` and `cubeb_stream_destroy` run in parallel, then the _cubeb stream_ may start playing while it's being destroyed.
    - `cubeb_stream_start` can be called __after__ checking `self.shutdown.load(Ordering::SeqCst)` in `destroy` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3386)
2. If `cubeb_stream_stop` and `cubeb_stream_destroy` run in parallel, then the _cubeb stream_ may stop twice (but it‘s probably harmless).
3. If `cubeb_stream_start` and `reinit` run in parallel, then _cubeb stream_ may start playing while it's being reinitialized.
    - `cubeb_stream_start` can be called __after__ checking `self.shutdown.load(Ordering::SeqCst)` in `destroy` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3239)
4. If `cubeb_stream_stop` and `reinit` run in parallel, then _cubeb stream_ may not stop successfully
    - `cubeb_stream_stop` can be called __after__ checking `self.shutdown.load(Ordering::SeqCst)` in `reinit` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3323).
5. If `cubeb_stream_destroy`  and `reinit` run in parallel, then the running callback may not be stopped while it's being destroyed.
    - The code for stopping the running callback in `cubeb_stream_destroy` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3386-3389) can be executed after `reinit` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3323) and before starting the existing callbacks [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3324)

These could be tested manually via the manual test added in https://github.com/ChunMinChang/cubeb-coreaudio-rs/pull/24/commits/148e57510bddb589b689852f8843be126dc0b675

For _1_ and _2_, it could be avoided if `cubeb_stream_start`, `cubeb_stream_stop` and `cubeb_stream_destroy` are run in the same task queue in gecko. For _3_, _4_, _5_, we need to fix those in the Rust backend.
Revision 1 by
on 
Several racing issues:
1. If `cubeb_stream_start` and `cubeb_stream_destroy` run in parallel, then the _cubeb stream_ may start playing while it's being destroyed.
    - `cubeb_stream_start` can be called __after__ checking `self.shutdown.load(Ordering::SeqCst)` in `destroy` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3386)
2. If `cubeb_stream_stop` and `cubeb_stream_destroy` run in parallel, then the _cubeb stream_ may stop twice (but it‘s probably harmless).
3. If `cubeb_stream_start` and `reinit` run in parallel, then _cubeb stream_ may start playing while it's being reinitialized.
    - `cubeb_stream_start` can be called __after__ checking `self.shutdown.load(Ordering::SeqCst)` in `destroy` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3239)
4. If `cubeb_stream_stop` and `reinit` run in parallel, then _cubeb stream_ may not stop successfully
    - `cubeb_stream_stop` can be called __after__ checking `self.shutdown.load(Ordering::SeqCst)` in `reinit` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3323).
5. If `cubeb_stream_destroy`  and `reinit` run in parallel, then the running callback may not be stopped while it's being destroyed.
    - The code for stopping the running callback in `cubeb_stream_destroy` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3386-3389) can be executed after `reinit` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3323) and before starting the existing callbacks [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3324)

These could be tested by the manual test added in https://github.com/ChunMinChang/cubeb-coreaudio-rs/pull/24/commits/148e57510bddb589b689852f8843be126dc0b675 , with some thread-sleep

For _1_ and _2_, it could be avoided if `cubeb_stream_start`, `cubeb_stream_stop` and `cubeb_stream_destroy` are run in the same task queue in gecko. For _3_, _4_, _5_, we need to fix those in the Rust backend.
Revision 2 by
on 
Several racing issues:
1. If `cubeb_stream_start` and `cubeb_stream_destroy` run in parallel, then the _cubeb stream_ may start playing while it's being destroyed.
    - `cubeb_stream_start` can be called __after__ checking `self.shutdown.load(Ordering::SeqCst)` in `destroy` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3386)
2. If `cubeb_stream_stop` and `cubeb_stream_destroy` run in parallel, then the _cubeb stream_ may stop twice (but it‘s probably harmless).
3. If `cubeb_stream_start` and `reinit` run in parallel, then _cubeb stream_ may start playing while it's being reinitialized.
    - `cubeb_stream_start` can be called __after__ checking `self.shutdown.load(Ordering::SeqCst)` in `reinit` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3239)
4. If `cubeb_stream_stop` and `reinit` run in parallel, then _cubeb stream_ may not stop successfully
    - `cubeb_stream_stop` can be called __after__ checking `self.shutdown.load(Ordering::SeqCst)` in `reinit` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3323).
5. If `cubeb_stream_destroy`  and `reinit` run in parallel, then the running callback may not be stopped while it's being destroyed.
    - The code for stopping the running callback in `cubeb_stream_destroy` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3386-3389) can be executed after `reinit` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3323) and before starting the existing callbacks [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3324)

These could be tested by the manual test added in https://github.com/ChunMinChang/cubeb-coreaudio-rs/pull/24/commits/148e57510bddb589b689852f8843be126dc0b675 , with some thread-sleep

For _1_ and _2_, it could be avoided if `cubeb_stream_start`, `cubeb_stream_stop` and `cubeb_stream_destroy` are run in the same task queue in gecko. For _3_, _4_, _5_, we need to fix those in the Rust backend.
Revision 3 by
on 
Several racing issues:
1. If `cubeb_stream_start` and `cubeb_stream_destroy` run in parallel, then the _cubeb stream_ may start playing while it's being destroyed.
    - `cubeb_stream_start` can be called __after__ stopping the running callback in `destroy` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3386-3389)
2. If `cubeb_stream_stop` and `cubeb_stream_destroy` run in parallel, then the _cubeb stream_ may stop twice (but it‘s probably harmless).
3. If `cubeb_stream_start` and `reinit` run in parallel, then _cubeb stream_ may start playing while it's being reinitialized.
    - `cubeb_stream_start` can be called __after__ checking `self.shutdown.load(Ordering::SeqCst)` in `reinit` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3239)
4. If `cubeb_stream_stop` and `reinit` run in parallel, then _cubeb stream_ may not stop successfully
    - `cubeb_stream_stop` can be called __after__ checking `self.shutdown.load(Ordering::SeqCst)` in `reinit` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3323).
5. If `cubeb_stream_destroy`  and `reinit` run in parallel, then the running callback may not be stopped while it's being destroyed.
    - The code for stopping the running callback in `cubeb_stream_destroy` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3386-3389) can be executed after `reinit` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3323) and before starting the existing callbacks [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3324)

These could be tested by the manual test added in https://github.com/ChunMinChang/cubeb-coreaudio-rs/pull/24/commits/148e57510bddb589b689852f8843be126dc0b675 , with some thread-sleep

For _1_ and _2_, it could be avoided if `cubeb_stream_start`, `cubeb_stream_stop` and `cubeb_stream_destroy` are run in the same task queue in gecko. For _3_, _4_, _5_, we need to fix those in the Rust backend.
Revision 4 by
on 
Several racing issues:
1. If `cubeb_stream_start` and `cubeb_stream_destroy` run in parallel, then the _cubeb stream_ may start playing while it's being destroyed.
    - `cubeb_stream_start` can be called __after__ stopping the running callback in `destroy` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3386-3389)
2. If `cubeb_stream_stop` and `cubeb_stream_destroy` run in parallel, then the _cubeb stream_ may stop twice (but it‘s probably harmless).
3. If `cubeb_stream_start` and `reinit` run in parallel, then _cubeb stream_ may start playing while it's being reinitialized.
    - `cubeb_stream_start` can be called __after__ checking `self.shutdown.load(Ordering::SeqCst)` in `reinit` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3239)
4. If `cubeb_stream_stop` and `reinit` run in parallel, then _cubeb stream_ may not stop successfully
    - `cubeb_stream_stop` can be called __after__ checking `self.shutdown.load(Ordering::SeqCst)` in `reinit` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3323).
5. If `cubeb_stream_destroy`  and `reinit` run in parallel, then the running callback may not be stopped while it's being destroyed.
    - The code for stopping the running callback in `cubeb_stream_destroy` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3386-3389) can be executed after `reinit` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3323) and before starting the existing callbacks [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3324)

These could be tested by the manual test added in https://github.com/ChunMinChang/cubeb-coreaudio-rs/pull/24/commits/148e57510bddb589b689852f8843be126dc0b675 , with some thread-sleep

For _1_ and _2_, they could be avoided if `cubeb_stream_start`, `cubeb_stream_stop` and `cubeb_stream_destroy` are run in the same task queue in gecko. For _3_, _4_, _5_, we need to fix those in the Rust backend.
Revision 5 by
on 
Several racing issues:
1. If `cubeb_stream_start` and `cubeb_stream_destroy` run in parallel, then the _cubeb stream_ may start playing while it's being destroyed.
    - `cubeb_stream_start` can be called __after__ stopping the running callback in `destroy` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3386-3389)
2. If `cubeb_stream_stop` and `cubeb_stream_destroy` run in parallel, then the _cubeb stream_ may stop twice (but it‘s probably harmless).
3. If `cubeb_stream_start` and `reinit` run in parallel, then _cubeb stream_ may start playing while it's being reinitialized.
    - `cubeb_stream_start` can be called __after__ checking `self.shutdown.load(Ordering::SeqCst)` in `reinit` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3239)
4. If `cubeb_stream_stop` and `reinit` run in parallel, then _cubeb stream_ may not stop successfully
    - `cubeb_stream_stop` can be called __after__ checking `self.shutdown.load(Ordering::SeqCst)` in `reinit` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3323).
5. If `cubeb_stream_destroy`  and `reinit` run in parallel, then the running callback may not be stopped while it's being destroyed.
    - The code for stopping the running callback in `cubeb_stream_destroy` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3386-3389) can be executed after `reinit` [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3323) and before starting the existing callbacks [here](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3324)

These could be tested by the manual test added in https://github.com/ChunMinChang/cubeb-coreaudio-rs/pull/24/commits/148e57510bddb589b689852f8843be126dc0b675 , with some thread-sleep added

For _1_ and _2_, they could be avoided if `cubeb_stream_start`, `cubeb_stream_stop` and `cubeb_stream_destroy` are run in the same task queue in gecko. For _3_, _4_, _5_, we need to fix those in the Rust backend.

Back to Bug 1598413 Comment 1