flukso
Callbacks occur in same coroutine that mqtt.new is called from
This causes issues for a few reasons. e.g. Coroutines can die:
local mqtt = require("mosquitto")
print("Main thread:", coroutine.running())
local client
do
local co = coroutine.create(function()
print("Calling mqtt.new from:", coroutine.running())
client = mqtt.new()
error() -- coroutine will now be dead.
end)
coroutine.resume(co)
print("THE STATUS OF ", co, "IS NOW: ", coroutine.status(co))
end
client:callback_set("ON_CONNECT", function()
print("On Connect called from:", coroutine.running())
client:subscribe("$SYS/#")
end)
client:callback_set("ON_MESSAGE", function(mid, topic, payload)
print("On Message called from:", coroutine.running())
print(topic, payload)
end)
client:connect()
client:loop_forever()
I'm not sure what you want to happen here?
e.g. callbacks could always happen in the thread that called loop_read/loop_write.
The idea that the loop_read/loop write is a different thread than the where mosquitto_new was called is somethign you're going to have to take up with mosquitto itself. I don't really see what we can possibly do with it here, this very much sounds like you're just violating mosquitto's idea of how to use a context object.
The idea that the loop_read/loop write is a different thread than the where mosquitto_new was called is somethign you're going to have to take up with mosquitto itself.
This issue is related to lua coroutines; not os threads; which is purely in the domain of lua bindings.
I'd suggest that your bindings to loop_read, loop_write and loop_misc save the L lua_State parameter somewhere for the C callbacks to use to call back into Lua.
You're going to have make a PR to show what you want here here. Having some of the routines try and use a "different" lua_State object depðending on whether it was from loop() or loop_read/loop_write sounds.... confusing to implement at least, let alone how the user will use it.