Hi Chris,
An alternative to incorporating Qt events into the mosquitto event
loop
would be to incorporate mosquitto events into Qt's event loop
(googling
suggests either QAbstractEventDispatcher or QSocketNotifier as
possibilities
to do it). However that probably entails reimplementing much, or
all, of the
existing libmosquitto(pp) - not sure if I'm up to that ...
I don't think it's as complicated as you suggest :)
I included what I hope is enough functionality to support this kind
of
problem, but whether it works in all cases remains to be seen. In
terms of adding the mosquitto event loop to an application already
using select() or similar, you would add the mosquitto client socket
to your fd sets using mosquitto_socket(), then if after the select
call it was ready for reading use mosquitto_loop_read() and for
writing mosquitto_loop_write(). You'd also call mosquitto_loop_misc()
to do the other bits as required (checking keepalive/ping and
retrying
messages).
Another less elegant way of doing it would be to call
mosquitto_loop()
with the timeout parameter set to zero. This would introduce a second
select() call to your own in order to monitor the mosquitto client
socket, but it would return straight away.
QSocketNotifier looks like a good candidate. You could create one
instance for notifying about read events and use it to call
mosquitto_loop_read() and another for write events that would call
mosquitto_loop_write(). There is the problem of what to do about
mosquitto_loop_misc() - putting it in the handler for the write
events
should be sufficient - in fact, putting it before the call to
mosquitto_loop_write() makes most sense as it may produce things for
loop write to do.
