[vlc-devel] [vlc-commits] lua: remove add_callback and del_callback

[Rémi Denis-Courmont]

On Thu, 29 Mar 2012 01:36:57 +0200, Pierre Ynard <linkfanel at yahoo.fr>
wrote:
>> vlc | branch: master | Rémi Denis-Courmont <remi at remlab.net> | Mon
>> Mar 26 17:38:49 2012 +0300| [fe5df3d5b1bbe4918e0997c1f9875b2f1eab281a]
|
>> committer: Rémi Denis-Courmont
>> 
>> lua: remove add_callback and del_callback
>> 
>> add_callback could not work correctly with the (lack of) Lua threading
>> support. Fortunately, it was not in use.
> 
> It's in use by extensions, that are now broken.

The _internal_  plugin API is explicitly unstable across major versions.
As far as VLC Lua exposes (a subset of) that API, it is unavoidably
unstable as well.
So that is a red herring

The *only* stable interface to LibVLC is well LibVLC proper. (Feel free to
write Lua bindings.)

You are trying to push a new responsibility on core maintainers. I
absolutely reject this. It has always been clear that the core API was not
going to be stable, and so should it be. It is already had enough to keep
LibVLC stable inspite of its legacy and lack of maintainers.

> The next victim will be
> the http interface, since httpd callbacks have the same problem.

"Told you so."

I spent several days of my own fixing the so-called "old" HTTP interface,
after I spent much of the previous years fixing synchronization and events
handling in VLC as a whole. I *did* warn that this needed to be done for
Lua too. Also ConfusedVorlon pointed out practical crashing race conditions
in Lua httpd way before 2.0 was out. Nobody cared.

I did not remove the old HTTP, nor did I initiate or get much involved in
Lua httpd. I do not accept any responsibility for this, and I am rather
annoyed that you point the finger at me here.

> These are important features.

So they are important. They also happen to be unstable.

Even if add_callback is restored, the core object variables are not
stable. So functionally, add_callback is intrinsically unstable anyway.

> I think the issue could be fixed by
> protecting the lua state with a mutex.

So there would be memory barriers and mutual exclusion. That does not
prove that the Lua interpreter can deal with this.
Also, that would turn the Lua plugin into a maintenance hell, as you would
need locking all over the place.

> For a callback to run, the main thread would have to either have exited,
> or be sleeping or polling or inside another such function;
> and two different callbacks would be mutually exclusive.

That would be unmaintainable. Locking would become so complicated that the
likelihood that someone gets it right would converge to zero.

For extensions and only for extensions, callbacks connection could simply
be queued instead of direct (which was buggy). Extensions already have a
mainloop. But that won't change the fact that object variables are not
stable. And that won't work for other types of Lua plugins.

-- 
Rémi Denis-Courmont
Sent from my collocated server