gnash-commit
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-commit] gnash ChangeLog server/asobj/NetStream.cpp serv... [g


From: strk
Subject: Re: [Gnash-commit] gnash ChangeLog server/asobj/NetStream.cpp serv... [gnash_0_8_3_branch]
Date: Tue, 20 May 2008 11:18:53 +0200

Great to see you in action ! :)

On Tue, May 20, 2008 at 08:02:55AM +0000, Bastiaan Jacques wrote:

>    switch ( mode ) {
>      case pauseModeToggle:
> -                     if ( m_pause ) {
> +                     if ( playbackStatus() == PLAY_PAUSED ) {
>                         unpausePlayback();
>                       } else {
>                         pausePlayback();

I belive the above snippet (and others below) suffer from a conceptual
bug about mutex locking.
As long as mutex is only locked inside the playbackStatus setter and
getter, there might still be race conditions in that you use the return
code of those functions while not holding a lock.

For example, if unpausePlayback sets status to PLAY_PLAYING
nothing prevents a thread to slip in between:

        if ( playbackStatus() == PLAY_PAUSED )

and

        {
                unpausePlayback();
        }

or the else body.

The consequence would be that unpausePlayback() is invoked while
already playing, or pausePlayback() is invoked while already paused.

This is similar to the issue with multithreaded_queue, which we now
stopped using..

--strk;








reply via email to

[Prev in Thread] Current Thread [Next in Thread]