Skip to content

[Bug]: BackgroundJobManager doesn't update JobInfo when changing name #264

@chrhaase

Description

@chrhaase

Detailed steps on how to reproduce the bug

Here's a simple unit test to reproduce:

TEST (BackgroundJobManager, JobNameCanBeUpdated)
{
    struct SimpleJob : ThreadPoolJobWithProgress
    {
        using ThreadPoolJobWithProgress::ThreadPoolJobWithProgress;

        ~SimpleJob() override { prepareForJobDeletion(); }

        JobStatus runJob() override { return jobNeedsRunningAgain; }
        float getCurrentTaskProgress() override { return 0.0f; }
    };

    juce::ScopedJuceInitialiser_GUI gui;
    SimpleJob job { "Old name" };
    BackgroundJobManager manager;

    manager.addJob (&job, false);
    job.setName ("New name");

    juce::MessageManager::getInstance()->runDispatchLoopUntil (100);

    EXPECT_EQ (manager.getJobInfo (0).name, "New name");
}

What is the expected behaviour?

I would expect JobInfo.name to reflect the new job name.
A simple fix may be to just add a line to BackgroundJobManager::updateJobs():

... // line 184
        {
            const juce::ScopedLock sl (jobsLock);

            for (int i = jobs.size(); --i >= 0;)
            {
                if (auto pair = jobs.getUnchecked (i))
                {
                    const float p = pair->job.getCurrentTaskProgress();
                    jassert (! std::isnan (p));
                    pair->info.progress = p;
                    pair->info.name = pair->job.getJobName(); // update the name!
                    newTotal += p;
                    ++numJobs;
                }
            }
        }
...

Now I'm thinking about it, I realise ThreadPoolJobWithProgress::setName() is not thread safe and needs to be called on the message thread anyway. So maybe the JobInfo could actually be updated synchronously. For my use case async is fine, but I guess setName could find the corresponding JobInfo in the manager and update it.

Unit test to reproduce the error?

Operating systems

macOS

What versions of the operating systems?

15.6.1

Architectures

ARM

Stacktrace

Plug-in formats (if applicable)

No response

Plug-in host applications (DAWs) (if applicable)

No response

Testing on the develop branch

The bug is present on the develop branch

Code of Conduct

  • I agree to follow the Code of Conduct

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions