Xarchiver branch

[Stephan Arts]

On 4/17/06, Benedikt Meurer <benedikt.meurer at unix-ag.uni-siegen.de> wrote:
> Stephan Arts wrote:
> > 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.
>
> My impression is that there is something wrong with the processing if it
> makes the UI sluggish while reading 60000 lines from a pipe. I guess you
> are trying to read one line per watch invocation, which would indeed
> explain the overhead. Why not simply use a non-blocking pipe and with
> each watch invocation you read whatever is available in the pipe?

That makes sense. I never thought about that.
I'll try that first, thank you.

> Benedikt

Stephan