I’m addressing those of you who understand the issues around running Xojo code in native OS threads, i.e. that it can lead to crashes.
I just had a thought come up on that and wanted to ask for input from those of you who are familiar with this topic:
We know that Xojo’s own threads are using native OS threads, and the Xojo runtime makes sure they do not run into issues by locking all but one of those threads at all times, so that the native OS thread scheduler can always only let one thread run. The runtime eventually unlocks another single thread (whenever a loop is being iterated, for instance), thereby keeping control over when it’s safe to switch to its other threads.
Now, the problem for us Xojo users is that when we use declares that use callbacks, it can happen that those callbacks occur in a pre-emptive thread not controlled by Xojo. If we then access any Xojo object from that thread, we’ll run the certain risk of crashing or other grave program misbehaviours.
So, I wonder:
Couldn’t we talk to the Xojo runtime’s thread scheduler, i.e. that code that decides when to lock/unlock its threads, and have this new thread calling our callback function be controlled by Xojo as well? All we need to do is invoke a runtime function that says:
Hey Xojo, this is a new thread you don’t know of - please lock it now and unlock it as soon as any of your other Xojo threads is ready to yield.
And before we leave this callback function, we’d again make a call into the runtime, saying:
Hey Xojo, we’re now leaving this thread. You can release and dispose of the lock on it again.
Any reason why this couldn’t work? If none are found, then I’d propose a feature request that adds such functions, e.g. to the System module, so that we can invoke them from our callbacks.
(Note: This is part of my research for my Multithreading session at the upcoming MBS Xojo conference in Munich next week.)