Xarchiver branch

[Stephan Arts]

On 4/17/06, Stephan Arts <psybsd at gmail.com> wrote:
> 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
>

I need to wait for the io_channel to close and the app (like tar) to
exit before i emit a signal. (Or we could miss rows which results in
an incomplete filled tree-model).

But this 'waiting' should not freeze xarchiver, any idea on how to do this?

Thanks,
Stephan