Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit c0178f10 authored by Andreas Huber's avatar Andreas Huber
Browse files

We are cancelling this event during reset, but the event may have already been...

We are cancelling this event during reset, but the event may have already been dispatched at the time, blocking on the mutex. While it's blocking, reset() cancels the event, we're then unblocked and bad things(tm) happen.

related-to-bug: 2451174
parent 0a026cff
Loading
Loading
Loading
Loading
+12 −0
Original line number Diff line number Diff line
@@ -401,6 +401,9 @@ void AwesomePlayer::notifyListener_l(int msg, int ext1, int ext2) {

void AwesomePlayer::onBufferingUpdate() {
    Mutex::Autolock autoLock(mLock);
    if (!mBufferingEventPending) {
        return;
    }
    mBufferingEventPending = false;

    if (mDurationUs >= 0) {
@@ -425,6 +428,9 @@ void AwesomePlayer::onStreamDone() {
    // Posted whenever any stream finishes playing.

    Mutex::Autolock autoLock(mLock);
    if (!mStreamDoneEventPending) {
        return;
    }
    mStreamDoneEventPending = false;

    if (mFlags & LOOPING) {
@@ -918,6 +924,12 @@ void AwesomePlayer::postCheckAudioStatusEvent_l() {

void AwesomePlayer::onCheckAudioStatus() {
    Mutex::Autolock autoLock(mLock);
    if (!mAudioStatusEventPending) {
        // Event was dispatched and while we were blocking on the mutex,
        // has already been cancelled.
        return;
    }

    mAudioStatusEventPending = false;

    if (mWatchForAudioSeekComplete && !mAudioPlayer->isSeeking()) {