host->i_url was read without protection. We also now use the reference
count as the "death" variable, rather than vlc_object_alive() which
simplifies locking.

By the way, its earlier (<= 0.8.6) incarnation were buggy.

By the way, the Win32 video outputs could probably go through some code
factorization. Don't ask me.

(Since we are always dealing with a pipe, it cannot return EINVAL)

Signed-off-by: Felix Paul Kühne <fkuehne@videolan.org>

Unbreaks start-up on WinCE.
Signed-off-by: Rémi Denis-Courmont <rdenis@simphalempin.com>

Pointed out by linkfanel.

Once the input main loop is done (or if input init fails), input
controls are not popped anyway. So the input callbacks are no-ops.
There is no point in postponing cleanup.

The only event that lock_and_wait can only wait for the end of the
interface event (safely). That is the only piece of state which is read
under the lock.

Also it is not possible to wait on a random object since (deprecated)
vlc_object_signal() is _not_ broadcasting the object condition variable.
In effect, VLC threads shall only wait on their own object (this is not
LUA-specific).

Ultimately, lock_and_wait is of barely any use, and in any case is now
poorly named (my fault for inventing vlc_object_lock_and_wait()). By the
way, it always returns true now.