[vlc-devel] [RFC] [NOT FOR MERGE] objres: add mutex support

Rémi Denis-Courmont remi at remlab.net
Wed Jan 29 09:08:09 CET 2020


Hi,

I'm more worried about the code churn. Accessing mutex only via pointers would allow hiding the internal layout. We don't do that *only* because we don't want vlc_mutex_init() to have error cases.

Conversions between compound type and pointer is not possible, so compilation would fail safely in case of confusion.

Le 29 janvier 2020 09:37:29 GMT+02:00, Thomas Guillem <thomas at gllm.fr> a écrit :
>Hello,
>
>I would prefer to avoid using a pointer to access a mutex.
>
>We will end up with modules using vlc_mutex_lock(sys->lock) and
>vlc_mutex_lock(&sys->lock).
>I think it will add more confusions.
>
>On Tue, Jan 28, 2020, at 21:30, Rémi Denis-Courmont wrote:
>> This adds a function to allocate a mutex that automatically gets
>> destroyed when a module fails or terminates.
>> 
>> I have very mixed feelings about this, as it introduces an error
>return
>> where there is normally none, i.e., from vlc_mutex_init(). It also
>> requires tedious rework to replace `vlc_mutex_t' with `vlc_mutex_t
>*'.
>> 
>> For reference, kernel code entirely solves this conundrum by not
>> requiring explicit mutex destruction (a kernel mutex does not hold
>any
>> resource besides its own `struct mutex' storage space). This could
>also
>> be done, but with significant reworking of the VLC threading layer
>and
>> prevents reliable detection of attempt to delete a still-in-use
>mutex.
>> ---
>>  include/vlc_objects.h |  2 ++
>>  src/misc/objres.c     | 15 +++++++++++++++
>>  2 files changed, 17 insertions(+)
>> 
>> diff --git a/include/vlc_objects.h b/include/vlc_objects.h
>> index 19ee5207fc..32f23abf41 100644
>> --- a/include/vlc_objects.h
>> +++ b/include/vlc_objects.h
>> @@ -295,5 +295,7 @@ VLC_API VLC_MALLOC char 
>> *vlc_obj_strdup(vlc_object_t *obj, const char *str);
>>   */
>>  VLC_API void vlc_obj_free(vlc_object_t *obj, void *ptr);
>>  
>> +VLC_API VLC_MALLOC vlc_mutex_t *vlc_obj_mutex_new(vlc_object_t
>*obj);
>> +
>>  /** @} */
>>  /** @} */
>> diff --git a/src/misc/objres.c b/src/misc/objres.c
>> index cac8624e7e..383dd760a8 100644
>> --- a/src/misc/objres.c
>> +++ b/src/misc/objres.c
>> @@ -174,3 +174,18 @@ void vlc_obj_free(vlc_object_t *obj, void *ptr)
>>  {
>>      vlc_objres_remove(obj, ptr, ptrcmp);
>>  }
>> +
>> +static void mutex_release(void *data)
>> +{
>> +    vlc_mutex_destroy(data);
>> +}
>> +
>> +vlc_mutex_t *vlc_obj_mutex_new(vlc_object_t *obj)
>> +{
>> +    vlc_mutex_t *mtx = vlc_objres_new(sizeof (*mtx), mutex_release);
>> +    if (mtx != NULL) {
>> +        vlc_mutex_init(mtx);
>> +        vlc_objres_push(obj, mtx);
>> +    }
>> +    return mtx;
>> +}
>> -- 
>> 2.25.0
>> 
>> _______________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel
>_______________________________________________
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
>https://mailman.videolan.org/listinfo/vlc-devel

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20200129/58cad4e5/attachment.html>


More information about the vlc-devel mailing list