wxMutex, wxCondition issues

[Jason Dolan]

Ok, so I've added this output code to wxapp_install_idle_handler():

#include
<iostream>                                                     //JD
void wxapp_install_idle_handler()
{
        std::cerr << ">>>>>>>>" << std::endl << "Entering idle
handler..." << std::endl;                                //JD
    if (wxTheApp == NULL)
        return;

#if wxUSE_THREADS
    wxMutexLocker lock(gs_idleTagsMutex);
#endif

    // Don't install the handler if it's already installed. This test
*MUST*
    // be done when gs_idleTagsMutex is locked!
    if (!g_isIdle)
 
{                                                                   //
JD
        std::cerr << "g_isIdle is FALSE! leaving idle handler" <<
std::endl << "<<<<<<<<<" << std::endl;        //JD
        return;
    }                                                                   //
JD

    // GD: this assert is raised when using the thread sample (which
works)
    //     so the test is probably not so easy. Can widget callbacks
be
    //     triggered from child threads and, if so, for which widgets?
    // wxASSERT_MSG( wxThread::IsMain() || gs_WakeUpIdle, wxT("attempt
to install idle handler from widget callback in child thread (should
be exclusively from wxWakeUpIdle)") );

    wxASSERT_MSG( wxTheApp->m_idleTag == 0, wxT("attempt to install
idle handler twice") );

    g_isIdle = false;

    // This routine gets called by all event handlers
    // indicating that the idle is over. It may also
    // get called from other thread for sending events
    // to the main thread (and processing these in
    // idle time). Very low priority.
    std::cerr << "m_idleTag was: " << wxTheApp->m_idleTag <<
std::endl;         //JD
    wxTheApp->m_idleTag = g_idle_add_full(G_PRIORITY_LOW,
wxapp_idle_callback, NULL, NULL);
    std::cerr << "m_idleTag is now: " << wxTheApp->m_idleTag <<
std::endl;      //JD
    std::cerr << "Leaving idle handler..." << std::endl << "<<<<<<<<<"
<< std::endl;   //JD

}

When I run my application, the point where it freezes looks like this:

Post message to gui thread
>>>>>>>>
Entering idle handler...
m_idleTag was: 0
m_idleTag is now: 1196
Leaving idle handler...
<<<<<<<<<
>>>>>>>>
Entering idle handler...
g_isIdle is FALSE! leaving idle handler
<<<<<<<<<
Starting to wait for event processing...
***Then it sits there waiting for me to wave my mouse over the
window***
***
***
***<moused waved over window>****
>>>>>>>>
Entering idle handler...
m_idleTag was: 0
m_idleTag is now: 1278
Leaving idle handler...
<<<<<<<<<
>>>>>>>>
Entering idle handler...
g_isIdle is FALSE! leaving idle handler
<<<<<<<<<
>>>>>>>>
Entering idle handler...
g_isIdle is FALSE! leaving idle handler
<<<<<<<<<
>>>>>>>>
Entering idle handler...
g_isIdle is FALSE! leaving idle handler
<<<<<<<<<
>>>>>>>>
Entering idle handler...
g_isIdle is FALSE! leaving idle handler
<<<<<<<<<
>>>>>>>>
Entering idle handler...
g_isIdle is FALSE! leaving idle handler
<<<<<<<<<
In WidgetControlHandler
Event processing complete.

So it appears to successfully wake up from idle, but it then goes back
into an idle state.  Perhaps there is a race condition where the app
becomes idle, we force it to become not idle, then it becomes idle
again... THEN the event is posted to the queue?