I'm doing this SDL program, and I wrote a lot of it on windows, where it worked fine. Then I had to program on linux for some time, and it worked there too. Now that I've returned to windows the program does not respond. The event handling code is the same and hasn't changed but here it is:
Ok, I tested it on the different operating systems, and the difference is that on Windows it does only respond to 4 - 6 events and then it stops responding to events and therefore Windows renders the program "Not responding". But it works on linux.
But a cursor blink thread stops working when Windows renders it "Not responding" and greys out.
Sounds like your threads are deadlocking. Probably what's happening is thread A is trying to lock a mutex that is owned by thread B... while thread B is waiting to lock a mutex owned by thread A -- so they both deadlock because neither mutex is freed.
That said... multithreading really adds tons of complexity to code (especially in games, where logic is mostly linear). Unless you have a really good reason to have multiple threads, you probably should just keep everything in a single thread.
There is no mutexes in my code, only 1 semaphore that locks down the rendering code. The reason why Windows "renders" it as using 0% is because it's using less than 1%( 0.XX% ) and is just displayed as 0% CPU.
Multithreading is needed if command input, background processes, networking , graphics and event handling should be possible to have at the same time.
There is no mutexes in my code, only 1 semaphore that locks down the rendering code.
Mutexes or semaphores. Both can cause deadlocks. It's hard to know if something is wrong because we can't see all the code. Where is the semaphore you talk about? Is the headers in the headers directory you own code or from a library?
The reason why Windows "renders" it as using 0% is because it's using less than 1%( 0.XX% ) and is just displayed as 0% CPU.
Remove the calls to SDL_Delay and see what you get.
Well the headers are class mostly class headers or modules, and all modules ( Except subnet.hpp/cpp) can be unplugged and we still get no difference to the "not responding" problem. The drawChar() is called from multiple threads, therefore it has a semaphore.