Currently libvlc uses "state" callback to notice input state changes, and the playlist notice input state change via direct call from the input.
playlist can't use the "state" variable as it is also used by the playlist to ask the input to do a certain action.

The event approach is much more clear here.

Pointed-out-by: Lukas

Pointed-out-by: Lukas

Some people should have read some documentation about threading before
they did 1000+ commits. Yes, I am obviously annoyed. I have been fixing
VLC for 18 months because of these "great former developers".

I assume nothing can ever try to add a new one once the interfaces have
been destroyed. If not there is a race condition.

Some (buggy?) thread implementations use RT signals internally...
The handling of SIGPIPE remains somewhat problematic. We should probably
use MSG_NOSIGNAL when writing to sockets, but this does not work when
dealing with pipes/FIFOs or writing to sockets using write(). In
particular, net_Write uses write() so that it can be used on non-socket
descriptors too (I believe this is used by the RC interface).

Though this should not happen as we are using non-blocking mode

Killing a the parent within vlc_object_attach looks like an awful hack
anyway. And there was a documented race condition, in addition to the
dead lock.

This reverts all the pluses from 99e8bcdd. vlc_object_kill() takes the
structure lock internally (through vlc_list_child()), so this would
always deadlock. Besides, we cannot take any lock within the structure
lock, lest we forbid any thread from ever manipulating the objects
structure while holding a lock on any object.
AFAIK, only object reference spins and the messages bank can be locked
within the structure lock.

filter. Since filter destruction is always requested by the subpicture
core itself, we already have the subpicture lock so no need to lock.

work.

possible to set this attribute at variable creation time (and for some
reason I don't understand that didn't work in one case so I added this
work arround :p)