Re: Why does "mapfile -d delim" (delim != '\n') use unbuffered read?

[Koichi Murase]

2021年5月5日(水) 6:18 Chet Ramey <chet.ramey@case.edu>:
> I used a combination of the simpler approach and the fstat/S_ISREG
> strategy you suggested in your previous email.

Thank you. I have tried the updated version of mapfile in 59c575fd.
Now it runs with temporary files as fast as the newline case.

$ TIMEFORMAT=%R
$ a=({000000..500000})
$ time printf '%s\0' "${a[@]}" > tmp
0.479
$ time mapfile -d '' b < tmp
0.050

It is 1000--2500x faster than the other approaches using `source' or `eval':

$ time declare -p a > tmp
0.065
$ unset a; time source tmp
49.762
$ unset a; time eval "$(< tmp)"
132.339

> >> (3) Suggestion: change the order of `run_callback' and `zsyncfd'?
> >
> > [...]
>
> I don't think this will make much of a difference -- it never has,

I suspect it's because the buffered read was only enabled when delim
== '\n' before and read(2) has read exactly until the delimiter in
most cases. Now we have changed that condition, so I guessed we want
to be more careful.

> and the state of the file during the callback's execution isn't
> defined

That's true... which was the reason that I wrote "I feel it is better"
instead of "We should" in the suggestion email. I think the result
becomes well-defined (i.e., predictable) with the new ordering of
`zsyncfd' and then `run_callback'.

--
Koichi