A few hours ago I was kinda desperate due to the bug I described in the last post. Couldn't really find out what caused to problem, but I knew that the only logical reason for this bug is a flaw in the resume/pause cycle. And yes, after some debugging I found something completely overlooked: the situation that happens when two threads try to resume a single thread at once. Some strange things will happen then: double qmutex locks on qmutex with two other qmutexes. Undefined behaviour indeed and should be prevented by some simple mechanic. I think I already figured a simple one, just need to implement it. I should do some stress testing with random ressource acquisition of multiple threads to see whether there are some more problems I didn't yet detected. One thing I learned with this project is that intense testing with a lot of "hey, what happens if I try this?" intiatives are very important for multithreaded code. The bigger the system becomes, the more unseen problems will happen and you have to find them. Actually, I'm quite happy that I was able to split everything in enough pieces to verify that they can't be part of a certain bug. This helped me a lot and still, there are so many things one should add for better debug output. Stuff like automatically spamming variable and so on - though in a wanted context. Or like masking out threads and whatever else. There are a lot of ideas in my mind but most of them aren't as useful as they are cool to have. Therefore, I'll rely on a simple, consistent setup I into, even if it's harder to decypher and slower to debug. But without a guess, even those nifty features won't help you that much. It's only quicker if you got a good direction, not more. So they aren't that much of use right now. Maybe later.
Anyway, there are only two exams left and my mood gets better and better as preperation becomes more nicely organized. That's good by default.