From: John Cowan <xxxxxx@ccil.org>
Date: Monday, November 25, 2019 11:59 AM
We've already discussed open/append. In the scenario where it makes the most sense to use, where multiple threads and/or processes might be writing to the file, it ensures that any call to write(2) is atomically added to the current end of the file, very handy for logging. This means any port using a file descriptor opened with it must not have output buffering, so that a single port output procedure call results in only one call to write(2), otherwise parts of strings could get interleaved with others. Skimming the relevant Chibi Scheme code, it looks like doing this will be trivial, as would changing the size of the output buffer from its default.
I don't think that should be enforced: I often open files for append even when I expect to be the only writer, in which case not buffering is very inefficient.
Indeed, I was reviewing our previous discussion about the case of multiple writers.
Should we mandate an optional no buffer argument to fdes->*output-port? Adding an option to change the buffer size to something non-zero and other than the default doesn't strike me as necessary for this SRFI, or perhaps necessary in general, and we want to limit what we demand of SRFI-170 implementors. In that case, we might name the argument to something like atomic-writes taking a boolean to make our intent clear.
Another option would be making the argument buffer-size, and not requiring implementation to support any value other than 0. Code using this would be most portable if a non-supported positive argument didn't raise an error, this is a performance rather than raw functionality option.
open/read and open/write by themselves, without using any of the above flags, don't make sense
Agreed; it's a degenerate case.
Not if you add set-port-position! to the mix, that's needed with binary output ports to recover backups correctly due to files with holes. And there's use cases like read only access to a database file.
compared to using the normal Scheme port procedures, unless you add set-port-position! AKA POSIX lseek to this or another SRFI.
However, if the textual conversion is specified in fdes->textual-port, then you do need plain open.
(At the same time, you'd naturally also add port-position to find out the current position (just another call to lseek with special arguments), and perhaps can-set-port-position?.)
I certainly do expect to have the R6RS port-position functions, but I don't think they belong in SRFI 170.
Then should we limit what flags, and their use, in SRFI-170? I.e. no open/read+write, no open/read without open/nofollow, etc.? I think it would be better to add appropriate notes and warnings in the SRFI about their limitations, and that they'll be (more) useful in future SRFIs.
That could be ignored, but not open/read+write, which doesn't make any sense without set-port-position! FilesAdvanceCowan specifies that switching between reading and writing first requires calling set-port-position!, which I assume is to invoke its buffer manipulating functionality.
That requirement comes from R6RS, which comes from stdio. See fseek().
Of course open/read+write opens an even bigger cans of worms, because you'll have to implement bi-directional ports. FilesAdvancedCowan lays out the minimum required behavior from the API, but obviously a noticeable amount of new work will be required to support them when starting from a Scheme implementation that sticks to the standards and only does unidirectional ports.
Yes, I'm good with making that behavior optional or leaving it out altogether.
Since there will be a SRFI that requires bi-directional ports, I think everything pertaining to it should be in it, except for including open/read+write etc. in this SRFI since it's trivial and natural to implement. With the above mentioned notes in the SRRI-170 text. Optional in SRFI-170, required in SRFI-Advanced-Files strikes me as confusing.
And then there's complexities with textual ports, which I will leave for the future depending on how much of the above extra functionality we decide is proper to demand from implementors of SRFI-170. Which is my closing question, where should we draw the line?
I think we need to be able to convert a fd to a textual input or output port, as we have now. The question is whether we need to have the detailed control, or just leave it to the Scheme implementation (which would presumably choose it based on things like $LANG and the OS name).
I have no informed opinion on this, will follow your lead.
- Harold