Why isn't there a MessageManager::callSync?

General JUCE discussion
1

Hi JUCE Team,

I was just wondering why there is no synchronous counterpart to MessageManager::callAsync. There is MessageManager::callFunctionOnMessageThread which is functionally what I want but it is a bit outdated and unwieldy to use.

A simple wrapper around that method would be make my code a lot less verbose. Something like this maybe:

MessageManager.h

/** Calls a lambda using the message-thread.
 *
 *  This method is the same as callFunctionOnMessageThread but allows you to invoke
 *  a lambda instead.
 */
static bool callSync(std::function<void()> functionToCall);

MessageManager.cpp

bool MessageManager::callSync(std::function<void()> functionToCall)
{
    auto* mm = MessageManager::instance;

    if (mm == nullptr || mm->quitMessagePosted.get() != 0)
        return false;

    mm->callFunctionOnMessageThread([] (void* userdata) -> void*
    {
        if (auto* f = static_cast<std::function<void()>*>(userdata))
            (*f)();
        return nullptr;
    }, &functionToCall);

    return true;
}

Thanks!

2

Nice idea. Isn’t the userdata in your implementation a dangling pointer, when it’s posted from another thread? Probably best to std::move the std::function into the lambda capture instead.

3

It’s not an issue as callFunctionOnMessageThread is executed synchronously. This means that callFunctionOnMessageThread will block until calling the lambda has finished. There will be no dangling pointers.

2 Likes
4

There also seems to be a ready to use implementation in juce_audio_processor.cpp

template <typename Callback>
void callOnMessageThread (Callback&& callback)
{
    if (MessageManager::getInstance()->existsAndIsLockedByCurrentThread())
    {
        callback();
        return;
    }

    WaitableEvent completionEvent;

    MessageManager::callAsync ([&callback, &completionEvent]
                               {
                                   callback();
                                   completionEvent.signal();
                               });

    completionEvent.wait();
}

that is also doing basically exactly what callSync would do. Any way this could be part of the public API?

2 Likes
5

Thanks for the suggestion, that’s added here:

Well spotted! I need to update that location to use the new function.

3 Likes
6

Thank you @reuk! This is perfect.

7

I’m not complaining about getting new functionality, but how is it that this FR was looked at, decisions had to be made and implemented and pushed to dev all within 24 hours, while simple bug fixes, or similarly simple FRs get ignored for months or even years?

From the outside it’s extremely bad optics that former JUCE teams’ request seem to get this preferred treatment.

Fabian needs a new feature? Must be 100% valid and very important. Better get on it right away. Anybody from the unwashed public needs a small feature or minor bug fix: how do we know how it affects the framework? Maybe fixing an off-by-one bug breaks the entire thing? Who can test all this, better leave it like it is. Until we’ve had a few years to think about it.

6 Likes
8

Totally agree. But priority is priority.

9

I’d say there’s a big difference between fixing bugs or making changes to existing functionality, and adding new features. Additions typically have 0 impact on the rest of the codebase and so are pretty risk-free to add, while bug fixes and changes could cause knock-on effects where trying to fix an issue for one user, you introduce a new issue for 10 other users.

But I do agree, it’s frustrating to have several open feature requests for things that can only be addressed in the framework itself but for them to be overshadowed by a feature that could easily be implemented in the user’s own codebase.

5 Likes