Xarchiver branch

[Benedikt Meurer]

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?

Benedikt