I think I asked Christian about those calls and he said that they were okay.
I’d be skeptical. What if you try replacing the MBS call with a simple Timer.CallLater(...) ? That might be a good test to eliminate one variable.
You can’t change a string. If two threads are trying to write to the same property, one will eventually clobber the other so you will need to protect that, but it won’t cause a crash.*
* If it does crash, report that as a bug.
The whole progress window works that way. I can remove all calls to CallDelegateOnMainThreadMBS and do some more testing.
But there are other crashes. One crash I get now and then involves HandleAppleEvent. If I switch to another app and then back to mine then HandleAppleEvent crashes.
When I cancel adding data to the database a database.flush crashes also.
Are all of these crashes also happening in code that is running within your CallDelegateOnMainThreadMBS MBS call and also within a Modal dialog? Could be a common cause…
Uh-oh, I’m seeing a crash in a little toy project. See: Preemptive Thread String Crash
3 Likes
Apple’s documentation is spotty but I have a sneaking hunch that pieces of the Apple Event framework code in OS X are not thread safe. Not that there’s much you can do about this fact from within Xojo. 
I’m just handling a GURL eventClass. And the crashing code is super simple:
dim AppleEventInfo() as string = DecodeURLComponent(theEvent.StringParam("----")).DefineEncoding(encodings.UTF8).Split("://")
My guess is that something running in the preemptive thread is corrupting the memory which eventually causes a crash somewhere completely random.
There is another thread relating to preemptive thread crashes using strings so you are possibly hitting a Xojo framework bug.
Impossible to say for sure. AppleEvent.StringParam does call out to the OS X AppleEvent framework, so that might be it.
But it will just as likely be fixed by Xojo as the preemptive framework is improved, too. Time will tell.
If your event is imperative only and doesn’t require a reply, you could try handing it off to a Timer to handle, which is guaranteed to run on the main thread.
I just started my first tests using Preemptive threads, and within an hour or two discovered a few serious issues:
- https://tracker.xojo.com/xojoinc/xojo/-/issues/77525
- https://tracker.xojo.com/xojoinc/xojo/-/issues/77526
- https://tracker.xojo.com/xojoinc/xojo/-/issues/77527
Perhaps one should consider Preemptive Threading to be in “Beta” status until some of these bugs are worked out?
Two of those are the same issue number - ?
Fixed
I do not use any timers.
My bug https://tracker.xojo.com/xojoinc/xojo/-/issues/77524 ( Hard crash in HandleAppleEvent when using preemptive threads) has a crash log that is similar to 77252:
| 1 libsystem_pthread.dylib | 0x19cfe43f8 _pthread_mutex_firstfit_lock_wait + 84 |
|---|---|
| 2 libsystem_pthread.dylib | 0x19cfe1dbc _pthread_mutex_firstfit_lock_slow + 220 |
| 3 libc++.1.dylib | 0x19cf1e758 std::__1::mutex::lock() + 16 |
| 4 XojoFramework | 0x1066069e4 ConvertTextMacOS(OpaqueTECObjectRef**, stringStorage*, unsigned int, unsigned int) + 60 |
| 5 XojoFramework | 0x106606d60 ConvertEncoding(string, unsigned int) + 280 |
| 6 XojoFramework | 0x106607374 ConvertToSameEncoding(string*, string*) + 244 |
| 7 XojoFramework | 0x106479a3c StringOpsClassic::CompareText(StringStorageBase*, StringStorageBase*, bool, bool) + 84 |
1 Like
Also in StringOpsClassic, just like my crash in https://tracker.xojo.com/xojoinc/xojo/-/issues/77525
A 4 core CPU has about 800% CPU to play with. 100% shouldn’t cause any problems for a primitive thread. It has its own core to keep it alive and running.
Surely sleep on the main thread should do nothing, as there are no other cooperative threads to allow to run.
Xojo’s scheduler surely isn’t involved in scheduling premtive threads, isn’t that the OS’s job?
Aren’t these threads within the app, unlike Workers, therefore it’s Xojo’s thread scheduler.
I’m pretty sure they are full blown operating system threads. Why would Xojo create something as complex as a preemptive thread scheduler when each OS has one built in.
Because OS threads are quite heavy, and within an app you can make it fairly light. We bought such a one in the 1980s used by a seller of boxes to multiplex serial connections over ethernet. Then adapted it to run under DEC’s VMS and IBM’s VM/CMS for another purpose.
Mind you, its that long since I’ve been involved in this sort of work so I’m probably totally out of date.