[FFmpeg-devel] [PATCH 1/3] avutil/log: add AV_LOG_ASYNC

anshul anshul.ffmpeg at gmail.com
Thu Mar 20 11:49:02 CET 2014


On 03/20/2014 02:46 PM, wm4 wrote:
> On Thu, 20 Mar 2014 14:07:05 +0530
> anshul <anshul.ffmpeg at gmail.com> wrote:
>
>> On 03/20/2014 11:54 AM, wm4 wrote:
>>> On Thu, 20 Mar 2014 03:57:57 +0100
>>> Michael Niedermayer <michaelni at gmx.at> wrote:
>>>
>>>
>>>> +/**
>>>> + * Do not thread synchronization.
>>>> + * This allows av_log() to be used from a signal handler but may lead to
>>>> + * garbled output.
>>>> + */
>>>> +#define AV_LOG_ASYNC 0x1000
>>>>    void av_log_set_flags(int arg);
>> Is there any special reason for value 0x1000
>> Why not 0x0002 or 0x0100?
> I suspect this is because of ABI compatibility with Libav. If they add
> a flag, FFmpeg couldn't be ABI compatible. (Nevermind that FFmpeg is
> too different from Libav anyway as that ABI compatibility would be
> usaful in practice.)
>
>> As per my understanding ASYNC and SKIP_REPEATED both flag change
>> properties of log mechanism.
>> so both should have similar numbering otherwise more properties related
>> flag would result in chaos.
>>
>> Since your changes are related to deadlock condition when same thread
>> apply lock twice, there may be better
>> approach if we check pthread_self().
>>
>> Some comments from manual of pthread_mutex_lock
>>          The mutex functions and the particular default settings of the
>> mutex attributes have been motivated by the desire to not preclude
>> fast,  inlined
>>          implementations of mutex locking and unlocking.
>>
>>          For  example, deadlocking on a double-lock is explicitly allowed
>> behavior in order to avoid requiring more overhead in the basic
>> mechanism than is
>>          absolutely necessary. (More "friendly" mutexes that detect
>> deadlock or that allow multiple locking by the same thread are easily
>> constructed  by
>>          the  user via the other mechanisms provided. For example,
>> pthread_self() can be used to record mutex ownership.) Implementations
>> might also choose
>>          to provide such extended features as options via special mutex
>> attributes.
>>> Just for ffmpeg.c? Please no...
>> This would help other application too, it is just now used in ffmpeg.c
>> will take time to adapt this feature by other application.
>> So yes
> No. I'm afraid that broken things will start to use it from other
> signal handlers too. Doing too much in signal handlers (even just
> logging) is insane, and I think *printf() is not even on the list of
> async signal safe functions.
>
> Instead, the code should be cleaned up not to call av_log from a signal
> handler.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
As per discussion with wm4 on irc.
sigterm_handler(int sig)
{
     received_sigterm = sig;
     received_nb_signals++;
     //we can remove one av_log from term_exit()
     term_exit();

      if(received_nb_signals > 3)
         //we can start new thread for exit_program, since most of our 
module are context locked
         //since exit_program wil run parallel
         exit_program(123);
}

-Anshul


More information about the ffmpeg-devel mailing list