Jonathan Nieder wrote: > [*] > I am not sure whether this is the right approach for reading from the > report-fd. To avoid deadlock, we cannot issue a blocking read(2) > after the trailing newline has been read from an expected line or the > nth byte has been read in fixed-length input. I think this isn't a problem (even though I haven't found any comforting text in the standards themselves). To convince myself so, I wrote a couple of new tests. The change descriptions explain the reasoning. These four patches apply on top of [PATCH 4/4] vcs-svn: teach line_buffer to handle multiple input files and are numbered accordingly. Thoughts welcome, as always. Jonathan Nieder (4): vcs-svn: make test-line-buffer input format more flexible tests: give vcs-svn/line_buffer its own test script vcs-svn: tweak test-line-buffer to not assume line-oriented input t0081 (line-buffer): add buffering test t/t0080-vcs-svn.sh | 54 --------------- t/t0081-line-buffer.sh | 174 ++++++++++++++++++++++++++++++++++++++++++++++++ test-line-buffer.c | 76 +++++++++++++++------ 3 files changed, 230 insertions(+), 74 deletions(-) create mode 100755 t/t0081-line-buffer.sh -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html