On Thu, Apr 2, 2015 at 2:17 PM, Martin Storsjö <[email protected]> wrote:
> The previous documentation was very vague and almost misleading.
> ---
>  libavcodec/internal.h | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> index a681329..c3dfaa1 100644
> --- a/libavcodec/internal.h
> +++ b/libavcodec/internal.h
> @@ -34,11 +34,16 @@
>  #include "config.h"
>
>  /**
> - * Codec is thread safe.
> + * The codec doesn't touch global variables in the init function, allowing
> + * running the init function without locking any global mutexes.

How about "The codec doesn't access any global variable in the init
function, allowing to call the init function without locking any
global mutexes."?

>   */
>  #define FF_CODEC_CAP_INIT_THREADSAFE        (1 << 0)
>  /**
> - * Codec cleans up memory on init failure.
> + * The codec allows (and requires) calling the close function for 
> deallocation
> + * even if the init function returned a failure. (Previously, without this
> + * capability flag, a codec does such cleanup internally when returning
> + * failures from the init function and does not expect the close function
> + * to be called at all.)

Not sure about this, is it the right place for documenting the current
behaviour?
I think something along the lines of "The codec automatically calls
the close function for deallocation should the init function fail for
any reason." would be better. If you think it's an improvement the
second part imho could be slightly reworded as "Otherwise, without
this capability flag, a codec does such cleanup within the init
function and does not expect the close function to be called at all."

Thanks for improving this section of the documentation.
-- 
Vittorio
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to