Ouch explodes when parallel decompression requires `stdin` interaction about ouch

[marcospb19]

A few ways out of this:

1. Regress decompression parallelism.
2. Create a complex system separating the main thread from decompression and compression threads so they communicate via messages, and the main thread handles the logic of outputting and reading input, so this never happens.

The latter is optimal, Ouch needs to separate the text outputting from the compression/decompression threads to achieve better performance and fix #77.

However, we don't have the workforce available to do such a system and maintain it in the long run, this project is stalled already with easy-to-fix bugs, so imagine having complex ones.

@figsoda thoughts?

[figsoda]

But how to stop output from other threads from getting in the way of Y/n prompts?

Good point, I don't think that's possible without having more complex system then

Do we stop all progress by holding a stderr lock?

I don't think it works just by holding the stderr lock. If you mean the static lock, I think that might have a performance implication if we have to check every time we print anything to stderr

[figsoda]

2. Create a complex system separating the main thread from decompression and compression threads so they communicate via messages, and the main thread handles the logic of outputting and reading input, so this never happens.

If we want a simpler solution, we can probably just have a static lock for Y/n prompts

[marcospb19]

If we want a simpler solution, we can probably just have a static lock for Y/n prompts

But how to stop output from other threads from getting in the way of Y/n prompts?

Do we stop all progress by holding a stderr lock?