[mythtv-users] 'Wakeup' Delay on Idle Frontend

Jim Stichnoth stichnot at gmail.com
Thu Dec 24 00:30:41 UTC 2009


On Wed, Dec 23, 2009 at 10:22 AM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> I don't think Greg found anything that fixed the problem, but we'd be very
> happy if you were able to.

Here is how I see things.  I looked at the mysql source code and it
appears that my_thread_global_end() is meant to be called at the end
of the application, and assumes that all threads that called
my_thread_init() have already called my_thread_end(), or at least will
within 5 seconds.  This implies that Qt4 does reference counting on
the number of database connections, and under some circumstances calls
my_thread_global_end() when the count hits 0.  I don't know that for
sure since I didn't feel like downloading half a gigabyte in the hope
of actually getting the source code, but it's the only reasonable
explanation of why those messages are showing up.

Here is one possible instance of the problem.
1. Thread A creates a new DB connection and then releases it into the pool.
2. Thread B starts soon thereafter and grabs and releases that
connection from the pool.
3. Much later (after the "idle timeout" period), thread B tries to get
a DB connection.
4. Thread B first purges that "idle" connection, reducing the number
of DB connections to zero.
5. Qt decides to call my_thread_global_end(), which waits in vain 5
seconds for thread A to exit, and then prints the error message.

At this point, I think MySQL's global variable THR_thread_count is
messed up, so any future calls to my_thread_global_end() will also
give this error.

In this example, thread A might be the playbackbox thread and thread B
is some different playback thread like the decoder or the video output
thread, and the problem starts up as soon as playback stops, assuming
playback lasts at least an hour.

If I'm right and this is really the root cause, then one solution is
to never let the number of DB connections go back down to 0.
PurgeIdleConnections() could easily enforce this by creating and
pooling a new connection as it purges the last remaining connection.
I will try this approach.

Jim


More information about the mythtv-users mailing list