I’ve run into a situation where I’d like to look at, and potentially operate on all the jobs in a ThreadPool. It would be helpful to have access to the currently private ThreadPool::lock member. Would you consider either adding an accessor or making the member protected so I can create a child class with an accessor?
Thanks much.
-DB
I could make it protected, though it’s the sort of class that isn’t really supposed to be subclassed - its internal workings could change in future and break your code. What exactly are you trying to do? There might be something else I could add that would let you do what you need.
I want to iterate through all the jobs in a ThreadPool and remove some of them. In this case, I’m using a subclass of ThreadPoolJob that has some other attribute I use to decide whether to remove or not.
So it’s similar to removeAllJobs but more like removeSomeJobs.
Hmm, yes, that sort of thing gets very hairy in terms of thread-safety with all those jobs coming and going. Maybe a method that takes a callback function and calls it for each of the active jobs, asking whether that job should be deleted?
I suppose some kind of callback would work but it feels way more complicated than making the member protected and allowing a child class to deal with it.
I think I changed my mind. The logic in ThreadPool::removeAllJobs is complicated enough that trying to get it right in a child class seems risky. A callback does seem better.
At long last, I’ve got a patch – a git diff. I can’t figure out how to attach it to the post. All of the extensions I choose are “not allowed.” What’s the best way to get you the patch?
Please don’t send me an actual patch file - I can’t stand messing about with them. I’d rather just compare your new file with my own version so I can easily see what the changes are.
I can send the whole file(s) (juce_ThreadPool.h and juce_ThreadPool.cpp). Should I just email them to you?