| Summary: | SDL_cond variables don't seem to get signaled reliably | ||
|---|---|---|---|
| Product: | SDL | Reporter: | spamcatcher |
| Component: | thread | Assignee: | Patrick Baggett <baggett.patrick> |
| Status: | RESOLVED ENDOFLIFE | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | baggett.patrick |
| Version: | 1.2.13 | ||
| Hardware: | x86_64 | ||
| OS: | Windows (XP) | ||
| Attachments: | Persistent thread C++ object | ||
The code I supplied is used to thread member methods of a class. It uses a template and will requires an object pointer and a member method function pointer to execute. I can make more code available if required. I'd like to take a crack at fixing this, but I'd need a minimal test case that can reliably deadlock the program. Hello, and sorry if you're getting several copies of this message by email, since we are closing many bugs at once here. We have decided to mark all SDL 1.2-related bugs as RESOLVED ENDOFLIFE, as we don't intend to work on SDL 1.2 any further, but didn't want to mark a large quantity of bugs as RESOLVED WONTFIX, to clearly show what was left unattended to and make it easily searchable. Our current focus is on SDL 2.0. If you are still having problems with an ENDOFLIFE bug, your absolute best option is to move your program to SDL2, as it will likely fix the problem by default, and give you access to modern platforms and tons of super-cool new features. Failing that, we _will_ accept small patches to fix these issues, and put them in revision control, although we do not intend to do any further official 1.2 releases. Failing that, please feel free to contact me directly by email (icculus@icculus.org) and we'll try to find some way to help you out of your situation. Thank you, --ryan. |
Created attachment 442 [details] Persistent thread C++ object I've created a simple persistent thread object (C++) to use in a pool. The object keeps a persistent thread running until destroyed. The thread can be given a function to execute. The thread function pseudo code looks like this while 1 wait for start condition to get singaled lock mutex do some work signal work finished condition unlock mutex Elsewhere in my code I wait for the work finished condition to be set. When using more than 1 (specifically 3 or 4) of these thread objects my programs end up in a deadlock waiting for the 'work finished' condition. I have verified that all the worker threads complete their assigned work and that they each sends the work finished signal. An ugly hack - aka. using polling loop instead of the finished condition variable - makes everything work as expected. I've attached the code. It should be completely portable, relying only on SDL.h and SDL_thread.h. My build environment is Visual studio 2008, and I'm running XP 32bit.