On Tue, Nov 2, 2021 at 4:54 PM Carlo Arenas <care...@gmail.com> wrote: > > On Tue, Nov 2, 2021 at 3:17 PM RVP <r...@sdf.org> wrote: > > > > Carlo, can you see if that works with your use-case? > > I only have a slow OpenBSD VM with current to test, so I am building a > port of your patch there (which seems will take several more hours to > build), I kept the "cheating" part there though, so not sure how much > useful my answer would be, but I expect it to work.
but it didn't work (even if it seems to be a step in the right direction); not sure if it was me who messed it up though, but building another iteration takes too long to know; will try with NetBSD current next. It did seem to help with `head -1` though, but even if their implementation uses stdio, it is doing character by character reads and no fseek, so the added code in fclose does the right thing and keeps the not consumed part of the stream available for the next caller. in my testcase[1] (and pcre2grep), we are using the buffer whole and need to fseek to get it to the right place if the read was overshot, but something else seems to be doing an lseek(0, 0, SEEK_CUR) at the end of the buffer read, and that conflicts with the new fclose code, setting the position to the wrong place for the next process, as a result (even if set correctly by doing an lseek through the -DWORKAROUND). an alternative implementation, might use to its advantage the fact that at close time the streams should be flushed and do the necessary seek there as required by fflush[2] in POSIX (seems that at least since SUSv3, an fflush(stdin) is a valid operation and should update the position of the underlying file)[3] Carlo [1] https://gist.githubusercontent.com/carenas/7c13147ef10365bec2595c9e87102ae7/raw/c6a98ddf22a171743a7dd8f3aad76c375c3301dc/f.sh [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/fflush.html [3] https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_05