Add Support for asynchronous callbacks on non-Xojo Owned threads

If you guys could add support for this case I just submitted on support for asynchronous callbacks that would be terrific. This case aims to vastly increase the power of Xojo iOS by allowing newer and more powerful APIs in AVFoundation, CoreML, and others to be accessed in Xojo.

<https://xojo.com/issue/55346>

Text of the case:

[quote]Many functions that can be called from declares in iOS and macOS now require callbacks that execute outside the main thread to be used in order to handle the results. This was first common with AVFoundation, and virtually all new libraries released by Apple in the last three years have followed the same paradigm.

Currently, limited hacks are possible by disabling bounds checking and stack overflow checking at the top of a callback method, but this is not a good general strategy because it greatly limits what can be done within the functions and also does not always work.

In order for Xojo to maintain some usefulness in the iOS development world, the addition of some method of invoking Xojo code as an asynchronous callback on a thread other than the main one is required.

This would ideally be in the form of a new type of iOSBlock like ‘iOSAsyncBlock’ that allows Xojo code to be run safely since many of the callbacks require a faster response than would be possible by shifting the invocation to the main thread. Shifting the call to the main thread would likely be an acceptable intermediate solution however if proper thread safety would not be possible.
[/quote]

Happy to say the case is now 28th after only a day. Hopefully Xojo will see the popularity and necessity of it so we can have this for 2019r2.

I don’t want to stop your enthusiasm, but the very similar <https://xojo.com/issue/9515> is about ten years old. And on place 3.

Well, the difficulties we had in plugin development is that, you not just need to do a timer thing or dispatch_async to main thread, but you also need to properly copy or retain/release the parameters for the call to main thread. Xojo can’t really know what the parameters are, so this will be difficult.

I wish Xojo had concentrated on preemptive thread support rather than white elephants such as D2D support, the new (now deprecated) framework and yet another HTTP comms implementation.

Operating systems and other frameworks are moving to async / threaded APIs and Xojo has really fallen behind. I can see a bleak future where Xojo cannot be used for anything more sophisticated than a database front-end unless it keeps up.

I somehow can’t fight the feeling of a déjà vue. Wasn’t it @Thomas Tempelmann who demonstrated on last year’s MBS conference how to use preemptive threads on macOS in both directions (as a callback and as a task) safely?

That was a hack and may work.
But the better system would be to define a delegate. Than you’d need to add attributes to mark which parameters need [NSObject retain], which need CFRetain() and which need structure copy.
And than let the runtime generate code to make a dispatch_Async to main thread or start a timer to run the delegate’s target method in a Xojo thread.

Yeah the difference though, at least to me, is that 9515 requires basically a complete rewrite of the language for thread safety while my request should just need an addition to it. The economics of 9515 don’t make sense unfortunately: Xojo would be spending significant money for something that is unlikely to attract new users. On the other hand 55346 will make iOS much more powerful so that people will stay with the language. It has seemed to me looking at the forum the last several years that many people stop iOS work in Xojo after not too long when many fundamental libraries from Apple cannot be used.

[quote=431174:@Christian Schmitz]That was a hack and may work.
But the better system would be to define a delegate. Than you’d need to add attributes to mark which parameters need [NSObject retain], which need CFRetain() and which need structure copy.
And than let the runtime generate code to make a dispatch_Async to main thread or start a timer to run the delegate’s target method in a Xojo thread.[/quote]
I don’t know the internals of iOSBlock, but I imagine they create a delegate from the function passed to it. Perhaps new data types of NSPtr and CFPtr could be added so the compiler is aware of what is needed when generating code, and then follow a similar procedure to iOSBlock in the async friendly version.

Theyre basically the same request
Any preemptive callback into ANY Xojo code requires a preemptive safe framework - which is what 9515 is asking for as well

[quote=431204:@Norman Palardy]Theyre basically the same request
Any preemptive callback into ANY Xojo code requires a preemptive safe framework - which is what 9515 is asking for as well[/quote]
Wouldn’t something that saves the parameters and then calls on the main thread not though?