@Sam R If I understood that correctly; I could in theory create a block of shared memory that contains a ptr to a NSDictionary, which would contain a NSURL and various NSObjects for handling the description of processing. Then on completion, the thread could also post to the shared memory a ptr containing the CGImage? Not worrying about memory management for the moment.
To be honest: I was a bit surprised about this thread because we did have this discussion a few times without much result. But so says Sam as OP, and if the purpose of this new thread is to collect the data:
Not only that. You can create NSDictionaries or NSArrays (or whatever) via declare inside the thread and pass them to a shared Xojo ptr or even forward them to a method installed in a custom NSObject subclass with PerformSelectorOnMainThread.
And Thomas has proven that you can do much more, even on Xojo level, in his MBS conference session. Also in the aforementioned opposite direction, when creating blocks by code that will or could be called from the system on a background thread.
I think it has been stated that this is becoming more and more important because Apple prefers them over class delegates like in the old days. Understandable because, hey, parallel computing! And if it were not for the background handling problems, blocks are way more faster to create in Xojo than hacking a delegate class.
I recently ran into a similar problem like Sam when working on a client’s project which is used to address several devices. The one I was trying to control on Windows uses the same "Register a thread to wait for an event"-approach, and of course waiting will stall Xojo’s thread scheduler. While I could work around most of this by time-slicing the events via their timeout thanks to an answer received here (but sadly not the main function which, when run on a Xojo thread, produces way less samples than the instrument’s manufacturer’s own solution), the only clean solution would have been to incorporate all that stuff into a (or several) console app(s). The customer’s reaction was to consider Xojo a worse solution for his project because many other modern languages do not have this limitation. I am afraid that he is not fully wrong. Thread handling currently is a minus point on Xojo’s side in the programming languages comparison chart. If there would even be an internal timeout timer that would force the thread scheduler to yield …
We all know Xojo has some very ambitious plans for future releases. I always forget the name of the programming law – "It will always take longer than you think, even if you consider that it will take longer", so pressing another topic to priority on the wish list could be overwhelming. Anyway, I sincerely hope this topic will gain more priority once the announced priorities are done. Even if it would mean some bigger limitations. We are used to be cautious when using a thread, so ok, have more limitations when using a background one. Should even be possible to include a check that issues a compiler error when you try to address a Xojo instance property from inside a preemptive thread for example. Thomas has proven that a lot of things can be done, and having such a solution available natively (I still did not succeed in changing his blocks example into something that can be used as easily as Joe Ranieri’s ObjC Blocks plugin) would be a great relief and alleviate one big current disadvantage. There is nothing really RADish in preemptive thread handling currently.