Ian Cotter-Llewellyn

I have since read @pfalcon's comment in PR #117: > guarantee that check_msg() return immediately and can be used in main loops doing something else (otherwise, check_msg() may block your...

Many thanks for the feedback @andrewleech. I've had another look at the code with your comments in mind. The setblocking() calls are both executed in the umqtt.simple module which knows...

@andrewleech, I'm resurrecting our month old conversation! :-) > check_msg should not continue to loop So a trivial code change brings your suggestion to fruition while also making `check_msg()` more...

Thank for the positive discourse @andrewleech. I saw that master has moved on a bit since my initial PR, so I've rebased, updated `manifest.py` and force pushed. Hopefully this is...

I've explored this issue and its comments and believe it can be closed: * In the OPs example, the behaviour is expected - the client must periodically `ping()` the broker,...

@pfalcon wrote: > Why not provide e.g. after_connect() method which should be subclasses and overriden by user? -1 for `after_connect()` or `on_connect()` - I also prefer to keep the underlying...

@andrewleech, if you had a moment to review + comment, I'd appreciate it.

Anything else I ought to do / address before this can go forward for merge?

Hey guys, any chance we can progress this to merge? If there's anything else to do beforehand, let me know.

@andrewleech, @dpgeorge, you guys seem like the people to be pestered! :rofl: (sorry). Are there reasons this PR shouldn't progress? If there's anything more I should do, please do tell.