2021年2月12日(金) 22:56 Chet Ramey <chet.ra...@case.edu>:
> >>> Thank you. Yes, if there is a simpler but still robust and reliable
> >>> way to do it, that would be nice.
> >>
> >> There is, in fact, a simpler way for this case. Blocking SIGCHLD around the
> >> calls to zread and its siblings fixes the problem. It might not be enough
> >> of a general solution for you, though.
> >
> > Thank you for the fix. Now I see why this particular form (CMD & read
> > -t) < XXX caused a significantly large timeout-failure rate. But, I
> > guess the failure rate is almost zero but not exactly zero even after
> > this fix.
>
> I can't reproduce the failure at all with the sigprocmask changes I added.
Sorry, I meant that there can be still other cases that may cause the
timeout failure. In fact, with the following shorter timeout, I can
reproduce the failure with the current commit 26db562 (but edited
configure.ac for release build) at least in my Linux.
#!/bin/bash
rm -f a.pipe
mkfifo a.pipe
exec 9<> a.pipe
rm -f a.pipe
for i in {0..99999}; do
printf '\r\e[K%d' "$i"
read -u 9 -t 0.000001
done
I personally don't use this particularly short timeout, but this shows
that the masked SIGCHLD is again another ``partial'' fix. Yesterday I
actually received an email from felix <fe...@f-hauri.ch> that he has
actually posted the same issue on the mailing list last October:
2021年2月12日(金) 16:11 felix <fe...@f-hauri.ch>:
> Sorry for delay... This seem linked to my post in october:
> https://lists.gnu.org/archive/html/bug-bash/2020-10/msg00095.html
> ( typo in subject: s/hand/hang/ ;)
Looking at his test cases, he seems to be interested in the timeout of
the order of microseconds. He also provided me with his new test case
to see the interaction with SIGCHLD. The failure of this test case
seems to have also involved SIGCHLD in the previous devel Bash. Now in
the current devel, it is improved but still sometimes blocks.
> For testing this, I wrote a small script revealing timeout failure by
> running `read -t` in a loop, ensuring some input after a delay..
> Adding `trap "echo -n ." SIGCHLD` give some enlightment:
>
> #!/bin/bash
>
> declare -p BASH_VERSI{NFO,ON}
> uptime
> uname -a
>
> innerLoop=${1:-3000}
> trap "echo -n ." SIGCHLD
> po() {
> for ((f=0;f<innerLoop;f++));do
> read -t .000001 v
> rc=$?
> [ $rc -ne 142 ] || [ "$v" ] &&
> echo f:$f, v:$v, RC:$rc.
> done < <(
> for i in {1..1000};do sleep 1;echo Timed;done
> )
> }
>
> exec 2>&1
> TIMEFORMAT="U:%U S:%S R:%R"
> for test in {1..20};do
> time po
> done
> exit 0
>
> --
> Félix Hauri - <fe...@f-hauri.ch> - http://www.f-hauri.ch
Anyway, although the SIGCHLD fix is not a perfect solution, it's
certainly true that it reduces the cases of timeout failures very
much. This fix is still important after the coming select/pselect
fixes since my suggested patches don't apply to the environment
without select/pselect. Thank you!
--
Koichi
