Re: How to handle long I/O operations

["Luciano Chavez" <chavez us ibm com>]

Taura,

Thanks for all the suggestions. I did leave out one crucial bit of
information on why fork() was not acceptable.

Basically, the disk intensive API call is part of an "engine" shared
library. On opening the engine, it internally allocates lists of disk
information anchored off global variables. It also opens a file descriptor
for a log and sets up signal handlers. Therefore, if I fork() then the
parent memory with the lists required by the API call I intend to call are
not there.

clone() might be an option and I see that I could specify the clone options
to share memory et al and I would need a mechanism such as a pipe and an
IOChannel along with an g_io_add_watch() so I can tell when the child has
written to the pipe the outcome (return code) of the API call.

Is clone() usually more acceptable than pthreads for a situation such as
mine? The man info on clone() recommends POSIX compliant threading packages
like pthreads.

regards,
Luciano Chavez


                                                                                                              
         
                    "Tara M"                                                                                  
         
                    <learfox furry ao net>         To:     "LIST: GTKAppDevel" <gtk-app-devel-list gnome org> 
         
                    Sent by:                       cc:                                                        
         
                    gtk-app-devel-list-admin       Subject:     Re: How to handle long I/O operations         
         
                    @gnome.org                                                                                
         
                                                                                                              
         
                                                                                                              
         
                    08/12/01 10:58 PM                                                                         
         
                    Please respond to "Tara                                                                   
         
                    M"                                                                                        
         
                                                                                                              
         
                                                                                                              
         




> 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