Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[mosquitto-dev] Windows Threading support for libmosquitto

Hello all,

I just recently joined this discussion list for the express purpose of bringing Native Windows threading support to libmosquitto on Windows to remove the pthreads requirement. I am fairly close to having a working debug build, then after that I want to add in the appropriate cmake commands so it builds appropriately for everyone else and can be merged into the project. For now I have just been manually compiling things/hacking them together.

Before that though, I have a few notes/questions for the group here.

1. Due to the absence of a pthread_cancel equivalent on Windows, the solution I have for scenarios where pthread_cancel would normally be used is to call mosquitto_disconnect on the object to force the thread to exit gracefully and just use WaitForSingleObject to wait until the thread exits. My question pertains to this having any ill-advisable side-effects. I don't think it will, as pthread_cancel is only called in mosquitto_loop_stop and mosquitto_destroy. In the case of mosquitto_destroy the object is being destroyed shortly thereafter and so it might be a little slower to destroy the object, but other than that there shouldn't be any side effects here (to my knowledge at least). For the other case, one would have to either call mosquitto_loop_start, which would properly reconnect, or alternatively call the non-threaded variants of mosquitto_loop afterwards. I'm not sure the side effects of stopping an async mosquitto object, then restarting it in synchronous manner, but I am unable to tell if this would cause a problem in mosquitto_loop. for mosquitto_loop to be called with a disconnected object. Lastly, it may just be bad style to disconnect a mosquitto object "in the background" at least, and so perhaps there are no technical objections here, but more of a stylistic implementation point.
So to summarize my first point, is there a reason to not call mosquitto_disconnect in mosquitto_loop_stop?

2. The dummypthread.h file will now be obsolete and replaced by what I have tentatively been calling mosquitto_threading.h and mosquitto_threading.c. In these files, I have defined a new struct mosquitto_thread_t and mosquitto_mutex_t that use #ifdef WIN32 to determine the type of the underlying object be it pthreads or Windows threading handles. My question here pertains to how important it is that when threading is disabled that the threading components evaluate directly to nothing as they do with the dummypthread.h file. In my implementation, in everywhere functions like pthread_mutex_lock and unlock are used, these will now evaluate to void functions that have no body if WITH_THREADING isn't defined or WITH_BROKER is defined, and thus won't be exactly the same. There won't be any threading operations done, but depending on the optimization level and compiler used, there may be unnecessary empty function calls allocated due to my current implementations, although there is nothing saying that it has to be so, just it means more work for me. Is this acceptable, or do all threading functions need to directly evaluate to nothing if threading support is disabled or is compiled with broker?

3. My last point isn't a question so much as a comment. I have been doing my development on GitHub (I forked the repo and pushed it up there, you can see my work in a dev branch so far here :, and I noticed that there was a post on this thread a few days ago regarding migration to GitHub. I am 100% in favor of this; I'm a GitHub fan. I think that GitHub has a very good process.

Ian Johnson
Wolfram Research

Back to the top