When using declares and Delegates to provide callback functions into Xojo from non-Xojo code, it can happen that such callbacks occur in an unsafe environment, mainly in a thread not currently controlled and secured by Xojo’s runtime.
As it seems, Xojo currently provides no safeguards against this, leading to random crashes. Those crashes are similar to those when using pre-emptive threads, against which Xojo engineerings keep advising us. Yet, in some cases, we have no control over this and hence simply need some support from Xojo here.
What I propose is that we get some kind of way to tell Xojo that we need thread protection for our callback function. I. e. that such code would get wrapped into something like a ‘performOnMainThread’ handler by the compiler. Or that we get a new AddressOf operator or Delegate constructor that adds such a wrapper. Anything that ensures that our callback is not called in a state that is unsafe in regards to Xojo’s cooperative thread management.
Joe will understand
I wonder even: Any delegate (eg. as created by AddressOf) has already a stub (handler) code anyway. I wonder if ut could even always check whether it’s running in a unsafe thread and act accordingly. Though that may have some significant performance impact, not sure. Joe should know.
Thomas, your thread is getting quite off-topic, hard to follow (no critique - I’m just explaining why I didn’t read thru it all now).
What I see from yours and Jason’s threads is that Norman keeps saying that it’s not working. Though I wonder if that’s just because Norman had some specific use cases in mind that for those it did not work.
For instance, I recently had brought up a case here where I used Joe’s Blocks plugin only to find out that it calls back into a non-safe thread as well. MBS had a solution that would instead transfer to the main thread, but that did not work either, because that block function got a CoreFoundation object passed that got autoreleased right after the call, so by the time the MBS-transfer-to-main-thread happened, the data was already gone. The solution here was to make the transfer synchronous to keep the object alive until after the main thread ran.
So, what I’m saying is that the Xojo engineers should revise the conditions and options, and maybe give us several options, as needed. I agree there’s no single solution that covers them all, but currently Xojo lacks badly in this regard because it just leads to random crashes, which is the worst.
The same is valid for OS threads that come in on a background thread. You must not use any Xojo instance, but you can address all kinds of datatypes and via their ptr representation OSX objects as well. This is unsupported and may stop working anytime, but I have things like that running reliably on OSX and iOS projects, like KeyChain results or even SceneKitView “events” that come in quite fast, and its possible to forward the background thread parameters to the Xojo instances with a few twists. Currently and without guarantee for the future.
I agree with Thomas: A performOnMainThread pragma would not be enough for many cases. But this is not trivial for the engineers, as currently Xojo tries to yield to any object you address which isnt thread-safe. I think an officially supported background thread ability would mean to change a lot of fundamental code.
And yet, those rules are not applicable to the issue with the Blocks issue I had recently (https://forum.xojo.com/3586-obj-c-blocks-as-callbacks - pretty much at the end of the thread where I point out that Joe’s plugin needs some improvement).
I started this thread in order to FIGURE OUT what can be done. Clearly, the Xojo guys do not want to spend time on that currently. SoI like to have other chime in. That requires, of course, that those chiming in actually know what’s going on in the runtime and how to write thread-safe code. Not many around of those, apparently
Xojo already gives us declares and delegates, i.e. we can already do all the bad stuff, and many users probably do not even see that some of it is dangerous because of being called in unsafe threads. Adding some code to the delegate stub may actually make their code safer, in the same way that a few years ago the runtime started detecting when doing UI calls from a thread, which was equally shaky. I rather have some extra code in the stub that at detects unsafe running in threads and reports an error instead of having apps randomly crash and the user not having a clue why. Once we’ve achieved that level of extra safety, we can go on and find out how to make it work better by analysing the use cases. But first, users need to be made aware of the issue, and most don’t, currently, I’m sure.
