Re: How to handle long I/O operations



            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?

    That will be all for the moment, once I understand this part, I might
have other question. We will see :-)


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: "Tara M" <learfox furry ao net>
To: "LIST: GTKAppDevel" <gtk-app-devel-list gnome org>
Sent: Monday, August 13, 2001 5:58 AM
Subject: Re: How to handle long I/O operations



On 12 Aug 2001 21:47:33 -0500, Luciano Chavez said:

Hello,

 I am wondering the best approach to coding for long operations occuring
 during a signal callback.



Hi, what you described sounds similar to a common situation that
I've dealt with. I'm not sure if our design would be applicatable
to your situation, but it's a very simple approach.

We have a primary management function that handles all per ``cycle''
instances that's called by GTK+ timeout. This timeout function
is to a short interval and the function handles the following:

Whenever a callback function generates a `job', a new structure
is alloated to the job list, the members of this structure are
filled with the important data, ie the FILE pointer if you were
downloading a file for example.

However once the job structure is allocated and set up (ie
a file being opened), the callback returns immediatly and does
nothing else.

Then as GTK+ control returns to toplevel, our management timeout
callback function is called, it then handles the list of jobs
per `cycle'.

I hope the tip helps you, let me know if you need a more detailed
explaination. Because this approach is very fundimental and dosen't
require anything fancy other than using GTK+'s timeout callback.


--
--
Sincerely,     ,"-_ \|/
-Capt. Taura M.     , O=__ --X--
.__      ,_JNMNNEO=_ /|\
OMNOUMmnne.      {OMMNNNEEEEOO=_
UOOOBIOOOEOMMn.       'LONMMMMNNEEEOOO=.__..,,..
UUOOEUUOOOOOOOObe        '"=OMMMMWNEEEOOOOO,"=OEEEOO=,._
OOUUUIEEIOONNOIUbe.    "7OMMMMNNNNNWWEEEEOOOOOO"   "'.
EEBNNMMMNWNWWEEIMMNe.   __  7EMMMNNNNNWWWEEEEEEEOO.   " .
NNMMMMWWWMMMWEINMMMNn "=BBEEEEMMMMMMMMNNNWWWEEOOOOO=._     .
  http://furry.ao.net/~learfox/



_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]