Description of Problem: Under some circumstances, my application's UI freezes but background threads still run. The following scenario causes it to happen: 1. Two threads; one, called CLI, handles the command line interface. The second, say WRK, does some work and prints messages to the console. 2. priority(CLI) > priority(WRK) (higher priority, not higher value) 3. While WRK is printing a message to stdout, the user hits RETURN which causes the CLI thread to wake up and display a prompt to stderr. This ends in cyg_libc_stdio_flush_all_but() with the CLI thread looping endlessly trying to flush stdout since WRK owns stdout stream's lock and cannot release it because of its lower priority. Version-Release number of selected component (if applicable): 1.5.2
[ Ideally I'll need a testcase.... ] I suspect what is required is to replace the mutex "trylock" with a lock when going through the loop a second time. This allows mutex priority inheritance to work properly. I'll look at it closer. Is this a contractual bug report or a contrib one? I suspect the former so I'll treat it as such :-).
I submitted this with my Ascom Contract hat on.
Created attachment 39408 [details] Simple test case
It took me a little longer than expected (I got bogged down trying to get debug hardware to work right), but this should hopefully solve it. I've tried it with your test case (with the cyg_thread_delay in worker() removed, to give it proper effect) and it appears happy. Can you confirm?
Created attachment 39647 [details] Here is the patch
Yes, the patch solves the problem. Thanks.
Great. I checked the patch into our CVS server at Solothurn.