idle loop callbacks

[Bob Caryl <bob fis-cal com>]

Hello all:

I just want to check a conclusion to which I've come against the 
knowledge out there concerning idle events.

In my application, I construct my window and call show_all_children in 
order to have the window displayed before I connect to the database that 
is used in the application.  If I can successfully connect to that 
database, I then call Gtk::Main::run; if not, I just call the window's 
hide() method and exit the application.

I have found that in order to see the window displayed before putting up 
a child window containing a progress bar while waiting for the database 
connection and subsequent retrieval of the data to be processed, I must 
use the following code before actually connecting to the database:

while(Gtk::Main::instance()->events_pending())
   Gtk::Main::instance()->iteration(FALSE);

This seems to work very well.  In addition to all this, I also have a 
class that is used to log certain diagnostic data to disk files if error 
conditions occur.  In order to prevent this logging from affecting the 
timing of certain time sensitive processess during disk I/O, I designed 
this class such that it puts these diagnostic messages into a memory 
array object that is then subsequently accessed by a callback function 
that is connected to the idle loop thusly:

Glib::signal_idle().connect( 
sigc::bind<gpointer>(&putMessagesToFile,(gpointer)this) );

from within the aforementioned class.   The callback function iterates 
the memory array writing each diagnostic message to disk and 
subsequently deleting each message from the array, and then it exits 
with a return value of TRUE.  In my class, I connect this callback to 
the idle loop until the class goes out of scope or is deleted in the 
case of a dynamically created version, whereupon it returns a FALSE and 
is discarded by the idle loop. 

I have described all this to lead up to my conclusion:  It appears that 
connecting this callback to the idle loop creates a defacto ever-present 
"event" that effects the return value of the 
Gtk::Main::instance()->events_pending() function.  I say this, because 
so long as my reporting class callback is connected to signal_idle, the 
events_pending loop never ends.

In order to workaround this phenomenon, I changed my reporting class 
such that the callback function is connected each time a diagnostic 
message is added to the array and the callback function always returns 
false when finishing it's job.  This has stopped the "hang" phenomenon.

So, is there something about the way I've implemented this scheme that 
is causing my problem or is it just an unhappy coincidence?

Thanks,

Bob Caryl