[FFmpeg-devel] default lock mechanism in libavcodec/utils.c

[anshul]

On 02/20/2014 12:49 PM, Reimar Döffinger wrote:
> On 20.02.2014, at 06:57, anshul <anshul.ffmpeg at gmail.com> wrote:
>> On 02/20/2014 12:41 AM, Reimar Döffinger wrote:
>>> On Wed, Feb 19, 2014 at 05:09:15PM +0530, anshul wrote:
>>>> On 02/19/2014 04:46 PM, wm4 wrote:
>>>>> This will lead to horrible stuff like library A trying to "unload"
>>>>> libavcodec, while library B is still using it. You can't generally use
>>>>> this function correctly.
>>>> How does that happen "when lib A is loading and lib B is unloading"
>>>>
>>>> What I understand is follow:
>>>> libavcodec  has been dynamically loaded by libA and libB
>>>> both does not know whether libA or libB  is using libavcodec
>>>> and if libA change some static parameter of libavcodec then libB
>>>> will also see the effect.
>>>>
>>>>
>>>> Something I have documented that this is dangerous(unsafe) function
>>>> if it is called when you dont know
>>>> whether any thing is using libavcodec.
>>> And when would you ever know that? Some user on your system might be
>>> using a libc they for fun linked against libavcodec.
>>> IMHO this is an example of an API that, at least strictly speaking,
>>> is _impossible_ to use correctly.
>>> At the very least, you couldn't let anything using this API get
>>> into a Linux distribution unless statically linked (which in turn
>>> would keep it out of many distributions).
>> If any X library that is using libavcodec, but your program(process) is not using the library X
> I don't know what that has to do with my example. My example is: your are using libavcodec and you use library X. You _cannot_ know whether X uses libavcodec or not, and if it does at which point of your program's runtime and in which thread (which means race conditions).
>
>> then you can surely state that there is no problem in unloading, because both of the program does
>> not share any section. All process have there own space and none interfere with other.
>>
>> i did wrote some test program to verify the above statement.
> I have 0 idea what your code is supposed to show or what it has to do with the issue.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Thanks Reimar Döffinger  for your elaboration.
According to your explanation, if a person know that
what all the are the dependency of his library (can be easily done by 
ldd) then at that situation he may use av_cleanup_on_lib_unload function.

This function can be useful when testing any feature of libavcodec too 
because each newcomer
does not know the whole story about why leakage is over there.

Just in my case there are 2 library which are having some similar 
leakage which does not
have any adverse effect, but to test that there will be no adverse 
effect of those memory
leakage I have to make long suite of test case. if there was positive 
report from from valgrind
I would be relaxed at least for program dying because of out of memory.

On 01/28/2014 08:31 PM, Michael Niedermayer wrote:

> if you had avcodec_unregister_all() you will have to deal with
> libgstreamer and libvlc calling it while your app is also
> calling it and maybe another lib calling register and yet another
> still using avcodec. all happening at the same time
>
> this can be solved in various ways, a lock and reference counting is
> one, another is to use some code that gets called on exit or
> lib unloading by the OS.
> I think none of these will be really easy to do portably
There was an another idea of michael that using reference count,
Reimar Döffinger if you want reference count then you can help me over 
there by some guideline, I have not implemented that idea because if i 
miss an reference count then that bug would take more time
to solve.

just now i am following below idea:

some code that gets called on exit or
lib unloading by the OS.

If you have any great idea other then what Michael gave, welcome :)

Thanks
Anshul