[vlc-devel] vlc_object_signal removal
olivier.aubert at liris.cnrs.fr
Mon Sep 8 14:28:07 CEST 2008
Thanks for the explanations. The fact is that wrt. your reasoning ("It
makes no sense to signal an object without _then_ changing some of its
data/state"), the locking mechanism is here used only for signalling,
not protecting the access to the object data. In other words, the code
in vout_intf.c knows that its caller has the lock for an object, and
that it will wait for a signal before reading it. Thus the vout_intf
code considers that it has the right to modify the object, as per a kind
of lock delegation.
As a aside note, if the vlc_object_signal vs. vlc_object_signal_unlocked
is such a big issue, then I think the vlc_object_wait doc should be
updated to reflect this. It currently reads:
* Waits for the object to be signaled (using vlc_object_signal()).
* It is assumed that the caller has locked the object. This function will
* unlock the object, and lock it again before returning.
* If the object was signaled before the caller locked the object, it is
* undefined whether the signal will be lost or will wake the process.
> In other words, the current snapshot support may currently:
> - wake up when it should not (detecting a bogus failure),
This does not really bother me.
> - miss the signal, and effectively deadlock.
This is more serious, but there is no real way of avoiding this, short
of a timeout mechanism, is there?
> As a side note, there are no less than two consecutive malloc/memcpy/free
> in that code path... and we are dealing with full RGB images here...
Not full RGB images: we are converting data to PNG. I admit that there
is a spurious malloc in the the mediacontrol_audio_video that could be
avoided. But it is not that critical.
More information about the vlc-devel