[FFmpeg-devel] [PATCH 1/3] lavc/pthread_frame: protect read state access in setup finish function
wm4
nfxjfg at googlemail.com
Fri Jan 13 20:13:10 EET 2017
On Fri, 13 Jan 2017 12:19:14 -0500
"Ronald S. Bultje" <rsbultje at gmail.com> wrote:
> Hi,
>
> On Fri, Jan 13, 2017 at 9:39 AM, wm4 <nfxjfg at googlemail.com> wrote:
>
> > On Fri, 13 Jan 2017 09:07:48 -0500
> > "Ronald S. Bultje" <rsbultje at gmail.com> wrote:
> >
> > > Hi,
> > >
> > > On Jan 13, 2017 6:40 AM, "Clément Bœsch" <u at pkh.me> wrote:
> > >
> > > From: Clément Bœsch <cboesch at gopro.com>
> > >
> > > ---
> > > libavcodec/pthread_frame.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> > > index 7ef5e9f6be..cb6d76284e 100644
> > > --- a/libavcodec/pthread_frame.c
> > > +++ b/libavcodec/pthread_frame.c
> > > @@ -509,11 +509,11 @@ void ff_thread_finish_setup(AVCodecContext
> > *avctx) {
> > >
> > > if (!(avctx->active_thread_type&FF_THREAD_FRAME)) return;
> > >
> > > + pthread_mutex_lock(&p->progress_mutex);
> > > if(p->state == STATE_SETUP_FINISHED){
> > > av_log(avctx, AV_LOG_WARNING, "Multiple ff_thread_finish_setup()
> > > calls\n");
> > > }
> > >
> > > - pthread_mutex_lock(&p->progress_mutex);
> > >
> > >
> > > This has a problem in that we're potentially calling an I/O function that
> > > potentially directly enters application space with a lock held.
> >
> > I think the user should be taking care of this (or just don't spam
> > av_log in a performance critical function). The log call here seems
> > more like an internal warning though, and I've never seen it happening.
> >
>
> But it's easy to resolve right?
>
> lock();
> int state = p->state;
> ..
> unlock();
> if (state == ..)
> av_log(..);
I still don't see what the problem is. Why make it more complex than
necessary?
More information about the ffmpeg-devel
mailing list