mosquitto-users team mailing list archive

[Andy Gelme <andyg@xxxxxxxxxxxxx>]

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.

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.

> 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 !

-- 
-O-  cheers  =  /\ /\/ /) `/ =
--O                           --  http://www.geekscape.org     --
OOO  --  andyg@xxxxxxxxxxxxx  --  http://twitter.com/geekscape --