Possible bug: Are multiple threads calling lua?

[Vhati]

I have an intf-event callback that acts on a variable periodically, but returns quietly when it hasn't been given a non-nil value.

When I set that variable from a dialog's button callback, I think I'm seeing threads fight.

u[n00ahfa5n058d]l elua generic warning: d vError while running script C:\Progr,
function (null)(): C:\Program Files\VLC\lua\modules\hmac.lua:126: attempt to cal
l a nil valuelc
excuenphtainodnl
ed vlc exception
unhandled vlc exception
u

A Windows Application Error popup keeps the console from winking out... sometimes.
I suspect there's a race condition going on. Adding debug messages and early returns indicates the click func is what's failing (in an innocuous spot at that), but it works when I comment out the timed func's add_callback(). The script seems to work so long as only one of them is running, but not both.

Lua doesn't innately have simultaneous threads, so if that's what's going on, several places in C might be triggering a shared lua interpreter without checking that it's already busy. Not good since Lua scripts don't have locking mechanisms to deal with that.

For now, I worked around it by having the click func's last line schedule the add_callback() to minimize their overlap, instead of activate().

Any thoughts?

[Vhati]

Hmm, doing occasional blocking stream reads in the intf-event callback lags video.
readline() was a little stuttery, but read() made VLC nearly unresponsive.
Even without dialogs.

[Vhati]

Oh, callbacks are known to be unstable and are unlikely to ever be fixed.
http://mailman.videolan.org/pipermail/v ... 87553.html

Okay then, I'll just write an external multi-threaded application and feed command strings to an interface script (based on cli.lua) via pipe or socket.