Re: How to handle long I/O operations

["Tara M" <learfox furry ao net>]

On Tue, 14 Aug 2001 12:01:15 -0500, Luciano Chavez said:

> Taura,
>  
>  You've been very helpful but I am still unclear as to how to handle the
>  work without threads in my case. I understood your job and timeout callback
>  example. In that example though, the I/O was assumed to be reading a
>  maximum stream of bytes, then possibly update a progress bar and end the
>  job if complete otherwise you would wait to continue the job on the next
>  timeout.
>  
>  In my case, I don't have the coupling between the points the I/O are done
>  and the ability to update a progress bar.

You mean your calculus engine is a serial control?

You should be able to call your calculus engine and perform
only a maximum set of calculations per itteration.


>  Here is some additional background, I am working on the Enterprise Volume
>  Management System (EVMS) project (http://sf.net/projects/evms). We are
>  trying to develop something like a superset of Linux LVM. The architecture
>  provides an engine layer that allows creating partitions, volumes, volume
>  groups, etc. in memory from user space. At some point the frontends call
>  evms_commit_changes() to allow the engine to run through the queues and
>  commit changes to disk. Certain operations, such as moves or slides of
>  partitions or volumes may take a considerate amount of time to complete
>  (think of sliding 100GB of data in a partition over by just a couple of
>  sectors).

I see, does the library or whatever you are using to perform
the actual work allow releasing of control during midwork for
progress updates/etc?

>  The evms_commit_changes() call that can be time and disk intensive is
>  currently synchrounous. In other words, it won't return until either an
>  error occurred in commit or the entire job of committing to disk is
>  complete.  So, while it does what it does, having a call to it in anything
>  that is called out by the main event loop would cause a freeze of the GUI.

Oh I see, hmph.  Can you split your program into two parts then?
Basically make yer progress updater a separate GTK+ app then?
That's what I would do in this case.



-- 
--
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/