FR: Thread message handling

This isn’t something I ‘require’ from Juce now, as I’ve written my own… however, it is something that would probably be very handy to be a part of Juce…

We already have an automatic system in place to safely invoke actions from the message thread, using the MessageListener class (driven by the MessageManager). However, there is no built in system for doing the reverse - sending a message to a custom thread.

I’ve found it very straightforward to implement in win32, though I’m not sure what it’d involve for the other platforms - windows at least creates a message queue for a thread automatically. Basically, I’ve given a Thread subclass postMessage(Message* const msg) and handleMessage(const Message& msg) funcs, and a processMessages() function to pump from the thread’s run loop. It works well, and means I can now use the same message ideology (and Message structure) to deliver events to my own thread from any other.

I think it’d be pretty useful if such a class were built into juce, especially as multi-threading programming is on the rise.

Any thoughts?

I’d second that. I rolled my own based on juce ownedarrays, and it works. I’m going to try to move it to lock-free in the next few days though. A canonical solution would be nice.


Yes, it’s a feature I’ve often fancied doing. Just a ‘MessageQueue’ class, really. Would be particularly nice if I could find a way to expose the same class for threads and for the main system event queue.

The only drawback I’ve found so far using the message queue ‘supplied with’ the thread (win32) is that there’s no immediately available way to allow for an optional synchronous/blocking call (a la callFunctionOnMessageThread()).

The MessageManager uses PostMessage for normal async, and SendMessage for synchronous; for threads, there’s PostThreadMessage, but no ‘SendThreadMessage’ - turns out I need to have an actual window callback for that to work, which means creating a dummy window too.

I can’t be arsed with all that :slight_smile: and I suppose really it’s probably more robust to attempt to ensure that the design works properly without such a feature… [or I could just be making excuses!]

… not really much point to this post, just a caveat i’ve discovered which might be handy to know should you implement such a feature using win32’s own message queueing.