Re: [mosquitto-dev] Windows Threading support for libmosquitto
Thanks, that's an interesting email.
> 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.
Ok. Is there a particular problem with the current implementations of
pthreads on Windows that you are trying to resolve?
> 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.
Calling mosquitto_disconnect() is something that should only be done
by the end user - it changes the behaviour of the client on the
broker. I'll mention that other pthread implementations have managed
> 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.
If we're assuming that the other windows pthreads implementations
aren't up to scratch, then I think I'd prefer to go down the route of
having code that implemented the pthreads functions in use in
mosquitto. That way the only change needed is to provide that code,
dummypthread.h still works as expected and the broker isn't affected
> 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.
FWIW, I'm not a big fan of adding typedefs for structs just to get rid
of the "struct". There's a good amount of text on the issue here:
I can't really see why you're bothering with a struct here anyway, why
not just something like the following?
typedef HANDLE mosquitto_mutex_t;
typedef pthread_mutex_t mosquitto_mutex_t;
That removes the extra malloc calls you need in some of your functions as well.
> 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.
I suppose it isn't extremely important, but on a matter of principle
I'd like that behaviour retained. It wouldn't be hard to do, it just
needs wider #ifdef clauses in the .c file and some support in the .h.
> 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 :
Thanks, it's useful to look at what you've done so far.
> 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.
Great, that's good to hear.
> Wolfram Research
So is this a work related project, or something you're doing in your
own time? :)