Diddy threading example crash
Monkey Forums/User Modules/Diddy threading example crash
| ||
| I was hoping to make use of threading to pipeline my rendering API more efficiently, but when I tried running the Diddy threading example in an empty project, it will run for a random amount of time and then crash with a memory access violation (no debug info) Anyone else had this or fixed it? Thanks! |
| ||
| Rendering (and anything Mojo) should only be done on the main thread in Monkey, due to the way Mark implemented the main loop. I'd suggest you keep the thread usage to coroutines and parallel processing, and avoid creating or destroying objects outside the main loop to make sure Monkey's garbage collection works correctly. Which example were you running, and which platform? |
| ||
| I created a blank mojo game project, copied in the 'threading' example code (the one with the Foo class), and tested it on Windows. The crash occurs after a random amount of time. I tried running the project through Visual Studio last night, and found that it was crashing somewhere inside the debug macros Monkey generates. If I deleted the macros, I didn't get the crash (well, not in the time I left it running, anyway). I suspect it could be related to the usage of globals inside those macros not being thread-safe. |
| ||
| It's possible there's a race condition with the stack trace generated by Monkey in debug builds. As far as I know, there's a single global stack trace for the entire application, and the translator inserts push/pop calls between every line of code. Since Monkey was never intended to be multi-threaded, it's likely that these are not thread-safe. Try building in release mode and see if you still have problems. |
| ||
| Yeah, that's what I thought. Since we're most pushed for performance on Android (and we never do debug builds on Android anyway), I may be able to salvage some sort of threading. Thanks! |
   |