[FFmpeg-devel] [PATCH 2/2] av_lockmgr_register defines behavior on failure.

[Michael Niedermayer]

On Tue, Sep 30, 2014 at 03:20:43PM -0700, Manfred Georg wrote:
> The register function now specifies that the user callback should
> leave things in the same state that it found them on failure but
> that failure to destroy is ignored by ffmpeg.  The register
> function is also now explicit about its behavior on failure (it now
> unregisters the previous callback and destroys all mutex).
> ---
>  libavcodec/avcodec.h | 24 +++++++++++++++---------
>  libavcodec/utils.c   | 31 +++++++++++++++++++++----------
>  2 files changed, 36 insertions(+), 19 deletions(-)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 94e82f7..69e7012 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -5120,16 +5120,22 @@ enum AVLockOp {
>  
>  /**
>   * Register a user provided lock manager supporting the operations
> - * specified by AVLockOp. mutex points to a (void *) where the
> - * lockmgr should store/get a pointer to a user allocated mutex. It's
> - * NULL upon AV_LOCK_CREATE and != NULL for all other ops.
> - *
> - * @param cb User defined callback. Note: FFmpeg may invoke calls to this
> - *           callback during the call to av_lockmgr_register().
> - *           Thus, the application must be prepared to handle that.
> + * specified by AVLockOp.  The "mutex" argument to the function points
> + * to a (void *) where the lockmgr should store/get a pointer to a user
> + * allocated mutex.  It is NULL upon AV_LOCK_CREATE and equal to the
> + * value left by the last call for all other ops.  If the lock manager
> + * is unable to perform the op then it should leave the mutex in the same
> + * state as when it was called.  However, when called with AV_LOCK_DESTROY
> + * the mutex will always be assumed to have been successfully destroyed.
> + * If av_lockmgr_register succeeds it will return 0, if it fails it will
> + * return -1 and destroy all mutex and unregister all callbacks.

generally ffmpeg uses negative for errors, so this shouldnt
specifically use just -1. This allows providing richer error codes
at any later point

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20141001/1c494346/attachment.asc>