<html><head></head><body>Hi,<br><br>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.<br><br>Conversions between compound type and pointer is not possible, so compilation would fail safely in case of confusion.<br><br><div class="gmail_quote">Le 29 janvier 2020 09:37:29 GMT+02:00, Thomas Guillem <thomas@gllm.fr> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Hello,<br><br>I would prefer to avoid using a pointer to access a mutex.<br><br>We will end up with modules using vlc_mutex_lock(sys->lock) and vlc_mutex_lock(&sys->lock).<br>I think it will add more confusions.<br><br>On Tue, Jan 28, 2020, at 21:30, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">This adds a function to allocate a mutex that automatically gets<br>destroyed when a module fails or terminates.<br><br>I have very mixed feelings about this, as it introduces an error return<br>where there is normally none, i.e., from vlc_mutex_init(). It also<br>requires tedious rework to replace `vlc_mutex_t' with `vlc_mutex_t *'.<br><br>For reference, kernel code entirely solves this conundrum by not<br>requiring explicit mutex destruction (a kernel mutex does not hold any<br>resource besides its own `struct mutex' storage space). This could also<br>be done, but with significant reworking of the VLC threading layer and<br>prevents reliable detection of attempt to delete a still-in-use mutex.<hr> include/vlc_objects.h | 2 ++<br> src/misc/objres.c | 15 +++++++++++++++<br> 2 files changed, 17 insertions(+)<br><br>diff --git a/include/vlc_objects.h b/include/vlc_objects.h<br>index 19ee5207fc..32f23abf41 100644<br>--- a/include/vlc_objects.h<br>+++ b/include/vlc_objects.h<br>@@ -295,5 +295,7 @@ VLC_API VLC_MALLOC char <br>*vlc_obj_strdup(vlc_object_t *obj, const char *str);<br> */<br> VLC_API void vlc_obj_free(vlc_object_t *obj, void *ptr);<br> <br>+VLC_API VLC_MALLOC vlc_mutex_t *vlc_obj_mutex_new(vlc_object_t *obj);<br>+<br> /** @} */<br> /** @} */<br>diff --git a/src/misc/objres.c b/src/misc/objres.c<br>index cac8624e7e..383dd760a8 100644<br>--- a/src/misc/objres.c<br>+++ b/src/misc/objres.c<br>@@ -174,3 +174,18 @@ void vlc_obj_free(vlc_object_t *obj, void *ptr)<br> {<br> vlc_objres_remove(obj, ptr, ptrcmp);<br> }<br>+<br>+static void mutex_release(void *data)<br>+{<br>+ vlc_mutex_destroy(data);<br>+}<br>+<br>+vlc_mutex_t *vlc_obj_mutex_new(vlc_object_t *obj)<br>+{<br>+ vlc_mutex_t *mtx = vlc_objres_new(sizeof (*mtx), mutex_release);<br>+ if (mtx != NULL) {<br>+ vlc_mutex_init(mtx);<br>+ vlc_objres_push(obj, mtx);<br>+ }<br>+ return mtx;<br>+}<br>-- <br>2.25.0<hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br></blockquote><hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>