Isaac Richards wrote:
Nope. Really need to fix the actual bug - ie., whatever's keeping things from returning threads to the pool. If it's just covered up like this, then it'll eventually have way too many threads running at once and cause other problems.Understandable. Is it possible for the thread pool to be exhausted normally? I would guess this could happen regularly when more than 5 sockets are open. What I'm curious about is that there is really only one place that puts threads back in the pool and this is surrounded by locks. The readSocket also has locks around the part which checks for an empty pool and gets a new thread. Is it possible that read socket (despite the usleep(50)) loops so quickly that the QMutex doesn't get a chance to see the unlock and in essence locks the MarkUnused function from ever getting a lock in order to replenish the queue? When I saw this error, the loop was executing very quickly:
2005-03-07 22:21:32.326 waiting for a thread.. 2005-03-07 22:21:32.346 waiting for a thread..
Is this a possible occurance? I guess logically it would seem not possible as the mutex unlock should unblock the waiting lock call in MarkUnused but who knows what really happens in there...
Kevin
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
