[vlc-devel] vlc_object_signal removal

[Olivier Aubert]

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.

Olivier