Re: How to handle long I/O operations

["Jean-Christophe Berthon" <jean-christophe berthon cgey com>]

Hy,

OK, so each time a callback is running, no others can be fired at the same
time as the one running "hold" the main loop. If I'm wrong tell me.
But you're speaking of the function gtk_idle_add. If I understand it
correctly : if I link my heavy function to this function, each time there is
no event to treat, the function is running. So to implement it I should do
something like :
 - in the callback of the "start calculus"
    idTimeout = gtk_timeout_add(500, function_show_activity,
(gpointer)NULL);
    idIdle = gtk_idle_add(function_calculating, struct_job);

 - in function_calculating
    /* My heavy calculus */
    /* ... */
    /* calculus finished */
    gtk_idle_remove(idIdle);
    gtk_timeout_remove(idTimeout);

Will it work as I'm expecting (excuting the calculus while showing an
activity bar and the calculus is execute only once!) ? Isn't it a
performance issue also? As the calculus is rather huge and with complicate
data, it has to be working efficiently. By doing it in "background", is it
going to be much slower (did you have any experience with that in fact?)?
And last question, how it is working? Because let say Gtk has nothing to do
(so he is idle) then the function_calculating is launch, but then the
timeout event trigger! So will it stop the function_calculating and execute
the timeout callback and then relaunch the idle function, or will it "hold"
the execution of the idle function while processing the timeout callback?

Thank you very much for your already usefull answer :-)


Best regards,
---
Jean-Christophe Berthon

Cap Gemini -- Ernst & Young
France
Skill Integration System -- Image Quality
Email: Jean-Christophe Berthon cgey com
Tel: (+33) 561 31 6639


----- Original Message -----
From: "Markus Lausser" <sgop users sourceforge net>
To: <gtk-app-devel-list gnome org>
Sent: Monday, August 13, 2001 3:11 PM
Subject: Re: How to handle long I/O operations


> On Mon, Aug 13, 2001 at 11:18:56AM +0200 Jean-Christophe Berthon wrote:
>
> >             Hello,
> >
> >     I'm interested in this behaviour also as we will have a callback
which
> > call a really long calculus (can take hours) And it would be interessant
to
> > see a progress or activity bar. And as we will need to function under
many
> > different Linux and UNIX, we cannot use pthreads (I've heard that they
were
> > suffering some portablilty issues).
> >
> >     So your solution is interesting me. But I didn't really understood
it
> > (I'm quite new to Gtk). So one first question that might enlight me :
When
> > you create a timeout (using gtk_timeout_add) with a period of a second
for
> > example, if another callback which will take let say about a minute is
> > fired. Does the callback attached to the timeout is fired still every
second
> > (while the other is computing at the same time) or does it wait to be
fired
> > until the other callback ends?
>
> No. There is a main loop in the GTK implementation that takes care of all
> events that are present (GUI events, Timeouts, read/writeable
> filedescriptors, etc. and last the idle functions). If you do a long
> calculation in a timeout function then the gtk main loop is not called, no
> other user defined functions are called nor is the GUI updated. You can
force
> it by calling single main loop iterations manually in your calc function
> from time to time (maybe in a loop there):
>
>   while (gtk_events_pending())
>     gtk_main_iteration();
>
> If you have also have added a timeout function that updates your progress
bar
> then your problem should be solved.
> "while (gtk_events_pending()) {};" could be dangerous, because it could
also
> block your calc function, if there is always a pending event (e.g. a idle
> function; dont know whether this is a "pending" event, but i am afraid it
> is). So a "if (gtk_events_pending()) {};" may be better.
>
> >     That will be all for the moment, once I understand this part, I
might
> > have other question. We will see :-)
>
> Feel free:)
>
> Markus
>
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list