[HN Gopher] Pipes, deadlocks, and strace annoyingly fixing them
___________________________________________________________________
Pipes, deadlocks, and strace annoyingly fixing them
Author : pabs3
Score : 52 points
Date : 2022-06-19 04:49 UTC (1 days ago)
(HTM) web link (changelog.complete.org)
(TXT) w3m dump (changelog.complete.org)
| khuey wrote:
| If `strace`ing a process fixes your problem you should try `perf
| trace`ing it instead. It works at a lower level (using kernel
| tracepoints rather than the ptrace API) so it disturbs the traced
| process less, at the cost of having less powerful output (it
| doesn't capture e.g. the actual data being written to a pipe).
| gigatexal wrote:
| Zfs can do encrypted backups so ... maybe this gpg stuff is
| unnecessary
| thomashabets2 wrote:
| This is tangental, but I would say never trust bash pipes.
|
| I wrote a tool to get around the problem:
|
| https://github.com/ThomasHabets/goodpipe
|
| I have more info about the problem in the README and this blog
| post: https://blog.habets.se/2021/06/The-uselessness-of-bash.html
|
| But tl;dr: If gpg fails in your example, then zfs receive will
| just think "oh that was all the data, apparently". Hopefully zfs
| receive is fine with that, and will notice it. But most tools
| would not.
| Joker_vD wrote:
| "Hey, I want to run N copies of this one program in parallel,
| and I also would like to be able to press Ctrl+C to stop them
| all at once, surely it's easy?" Yes, but only if you know the
| right spell: (trap 'kill 0' SIGINT; for i in
| {1..$N} ; do this_one_program $i & done ; wait)
|
| I've seen quote enough of coworkers who struggled trying to
| Ctrl-C the &-ed copies of programs from a single shell, only to
| give up and run them from several xterm windows/Terminator tabs
| instead, can't really blame them.
| Filligree wrote:
| GNU Parallel handles this nicely, and is quite a powerful GNU
| toolbox of GNU as well. I use it quite a lot. GNU. Don't mix
| it up with the (IIRC) Suckless tool of the same name, which
| is significantly less powerful. GNU.
|
| Just be prepared to silence the GNU.
| metadat wrote:
| I don't use gnu parallel because it is not installed by
| default. Xargs on the other hand, is.
| nolist_policy wrote:
| set -o pipefail
|
| is your friend
| thomashabets2 wrote:
| I mention this in the blog post. It doesn't fix the big
| problem. If fixes a smaller problem only.
| kasabali wrote:
| Would $PIPESTATUS be a solution for the 'sort fails' issue in
| your blog post?
| fluidcruft wrote:
| goodpipe looks interesting! My first thought is that it seems
| to lack support for bash file descriptor things that I often
| rely on.
| kazinator wrote:
| Something hanging is not automatically a "deadlock". If you
| jiggle it and starts moving again, that tends to be evidence
| against the deadlock hypothesis. It could be a lost wakeup
| problem. If something is blocked on a write due to a lost wakeup
| problem, what it means is that the task was preparing to block a
| due to no buffer space just around the moment when space became
| available. Due to a race condition, it blocked anyway, missing
| the "buffer available" event.
|
| Lost wakeup problems are more readily susceptible to recovery by
| "jiggling" the situation than deadlocks. If there is a deadly
| embrace situation, and you randomly wake up some involved task
| (in such a way that it doesn't just error out) it will typically
| just spin around and wait again, re-engaging with the deadlock.
| You can interrupt deadlocks in a breakpoint debugger, and when
| you hit "go" again, the deadlock typically continues.
| WesolyKubeczek wrote:
| For me, the "-T0" in zstdcat raises major alarm bells. There
| doesn't exist a simple problem that cannot be made an utter
| clusterfuck by adding multithreading.
|
| (If you have a single, unseekable stream of bytes on input, and
| one output stream, the usefulness of threads is evading me.)
| vlovich123 wrote:
| Your CPU time processing the bytes greatly exceeds the I/O time
| reading them off the wire (not to mention generally pipelining
| I/O and CPU activities).
| WesolyKubeczek wrote:
| This "greatly", in case of zstd, is where citation is needed.
| WesolyKubeczek wrote:
| My point still stands. Multithreading is not something you
| "just" throw in. It's riddled with unexpected gotchas you
| didn't know you had in your own code, plus all quirkiness of
| the underlying libc and OS.
| heinrich5991 wrote:
| The amount of unexpected gotchas varies greatly by the
| programming language you use.
| Filligree wrote:
| True. Most of my Rust tools are multithreaded, and this
| has never caused trouble.
|
| But zstd is written in C, is it not?
| rincebrain wrote:
| People may find the author's bug [1], the first time someone
| reported the bug I suspect this is to the project [2], the
| associated workaround [3], or the kernel.org bugzilla entry [4],
| interesting.
|
| [1] - https://github.com/openzfs/zfs/issues/13571
|
| [2] - https://github.com/openzfs/zfs/issues/13232
|
| [3] - https://github.com/openzfs/zfs/pull/13309
|
| [4] - https://bugzilla.kernel.org/show_bug.cgi?id=212295
___________________________________________________________________
(page generated 2022-06-20 23:02 UTC)