Xarchiver branch

[Stephan Arts]

On 4/14/06, Stephan Arts <psybsd at gmail.com> wrote:
> On 4/14/06, Benedikt Meurer <benedikt.meurer at unix-ag.uni-siegen.de> wrote:
> > Stephan Arts wrote:
> > >>>>I have a local copy of xarchiver that has the following changes with
> > >>>>whats in svn-trunk.
> > >>>>
> > >>>>- libxarchiver uses Gobject derived objects
> > >>>>- libxarchiver handles spawned processes in another way
> > >>>>
> > >>>>- support for anything else then gzip and tar has been removed for
> > >>>>testing purposes.
> > >>>>
> > >>>>Work in progress:
> > >>>>- libxarchiver will work with signals to notify the GUI it can update
> > >>>>the treeview.
> > >>>>(idea is to let the GUI respond while libxarchiver is busy, current
> > >>>>version makes GUI hold)
> > >>>
> > >>>My copy is also the first version incorporating threads to do this.
> > >>>It is easier to test the threading-model if i only have 1 or 2 archive
> > >>>types to maintain. But this would make it difficult for Giuseppe to
> > >>>test the support stuff we already have.
> > >>
> > >>Why do you want to use threads? The archive processes already run
> > >>asynchronously (tar, unrar, unzip, etc.).
> > >
> > > Because then we still process the data synchronously and that makes
> > > the GUI freeze with large archives. using a separate thread to parse
> > > the output fixes it.
> >
> > Hm, how about trying to optimize the parsing code. It cannot be that
> > hard, or atleast its worth the effort if it helps to avoid adding
> > complicated thread handling.
> >
> > Benedikt
>
> I have removed most of the extra threading code, it seems that the
> addition of the xa_data_ready signal fixed the freeze by itself.
>
> I will be testing around with the tar implementation a bit for the
> next few days.
> It seems to work now, without being that complicated, i will clean up
> some library functions to make more sense and then i can catch-up on
> the GUI-side again.

Some more testing with adding files to the archive let me to conclude
the 'unthreaded' situation is far from ideal. It gives the impression
we are dealing with a 'bloated' app, just because it takes time to
read the data from the channel (app cant write it faster then it is
running)

I have continued working on the threading model, tested around with
it, and the only issue i have atm is that the list-store (i still use)
is not thread-safe.

Since i need to implement a new tree-model anyway i will make that thread-safe.

There are at most three threads at work at any time (+ spawned app).
  - the main-thread
  - the exection-thread
        (executing the application and reading the channels)
  - the watch(dog)-thread
        (waiting for program execution to finish, join
execution-thread and close PID,
         and emitting the signal it should emit when done)

As you can see, the threading is not that complicated. Because there
are few shared resources I need only two mutex-objects inside the
library, and (as far as i can see now) a thread-safe tree-model +
mutexes around the set-sensitive code for the buttons.

If this gives the user the feeling the Xarchiver is flying, for me
that is worth the efford.

> Stephan
>