← Back to team overview

mosquitto-users team mailing list archive

  1. mosquitto-users team
  2. Mailing list archive
  3. Message #00138

Re: using libmosquitto in an external event loop

  Thread Previous • Date Previous • • Thread Next 
Hello Andy,
Please find my comments inline. Since our discussion is a bit off-topic for the mosquitto mailing list, I'd like to focus on the original question:
Looking at the mosquitto_loop code shows that if a read or write error occurs, the socket is closed with the private _mosquitto_socket_close function, which updates the internal mosq state as well. This means that the current libmosquitto API doesn't allow a proper implementation in an external event loop. Making _mosquitto_socket_close public would be a start. Integrating the rc handling of: 
* rc = mosquitto_loop_read(mosq, max_packets)
* rc = mosquitto_loop_write(mosq, max_packets)
inside these public functions could be an even cleaner approach.

Would such a code change be an option? I can work on a patch if needed.

Cheers
/Bart

On 12/13/2012 01:57 AM, Andy Gelme wrote:

hi Bart,

On 2012-12-13 10:06 , Bart Van Der Meerssche wrote:

Hi Andy^2


I suspect that I'm at least Andy^3 (or later) in the time-line of MQTT.


My use case includes listening on multiple sockets/pipes/devs
simultaneously, processing and then passing on the message. mqtt_lua
is not evented AFAIK. You need to call mqtt_client:handler() every
second or so, much like mosquitto_loop.


Yes, given that off-the-shelf Lua is single-threaded and cooperative
co-routines are the standard approach ... that drove the MQTT Lua client
down the path of providing "mqtt_client:handler()" within a poll loop,
which then invokes your callback.
That's indeed the most sane approach for a 'pure' mqtt client. However, my use case involves listening on multiple sockets/pipes & an spidev. 


Under the covers, the LuaSocket library provides a given set of
functions and "socket.select()" is used to check if any in-bound MQTT
packets have been received, as follows ...

   read_sockets, write_sockets, error_state =
socket.select({socket_client}, nil, 0.001)


I like the fact that libmosquitto allows loop polling, integration
with an external event loop and a threaded approach with internal
event loop.


There are a number of approaches for bringing multiple threads to Lua ...

    http://kotisivu.dnainternet.net/askok/bin/lanes/comparison.html

... and if you have a particular preference, we could investigate how
best to put a blocking socket select() call on another thread, which
then invokes the "mqtt_client:handler()" as soon as an in-bound MQTT
packet is available for parsing.  Thus, avoiding a poll loop.
1/ Most of these libs create a Lua state per thread. That doesn't solve our problem. Your callbacks will happen in one Lua state while the main code will run in the other Lua state. So you'd have to work with message passing between states, e.g. using pipes. But then you'd still have to include the pipe fd into the select/poll of the main Lua state. Feels like an unnecessary complication to me. 2/ The only 'real' multi-threaded Lua implementation is Diego Nehab's. But this requires you to patch Lua core, making it incompatible with a default Lua installation. He also removed the LuaThread patches from his home page. You can still find them on the net, but you'll be on your own in treacherous mutex-land.
Integrating loop_read/write/misc into a single poll/select allows us to keep Lua mono-threaded and still have low message latency. 


On 12/12/2012 10:43 PM, andypiperuk@xxxxxxxxx wrote:

You know that the Eclipse Paho project has a Lua client due to hit
Git within days, right?


Right you are !

References

  Thread Previous • Date Previous • • Thread Next