From: John Cowan <xxxxxx@ccil.org>
Date: Wednesday, April 22, 2020 3:42 PM

On Wed, Apr 22, 2020 at 1:13 PM <xxxxxx@ancell-ent.com> wrote:

[...]

In this fdes->*-port context, do we want to add language, and possibly required behavior, about what to do with a file descriptor created with open-file with the open/read+write flag?  That's a non-process related case where a GC implicit close of a file descriptor from an abandoned port could be bad, in a way that's not obvious to the user.

Please explain further.

This pertains to what we intend to support with the open/read+write flag to open-file in the Scheme domain.  Not sure it makes sense unless you also have SRFI 192's set-port-position!, but let's assume you use both fdes->*-input-port and fdes->*-output-port on the returned file descriptor, and then read and write to those ports, with set-port-position! implicitly changing the position of both a read or write after it calls lseek().

To make this sane, the implementor has to flush all read port buffers using the same file descriptor after a set-port-position! is made on a port using it.  Which is fairly ugly, for fdes->*-port he'll have to iterate over all his opened ports to see if this new port has the same file descriptor as a previously opened one, and then link them so a set-port-position! to any port will do the right thing all the read port buffers.  Otherwise, it's simple, the position is a property of the underlying file descriptor.

So I was supposing the user abandons one of these ports before finishing with another, it gets GCed, and that closes the underlying file descriptor.  If he attempts another operation on the other port, it will fail, and the cause won't be immediately and intuitively obvious.

An answer is in the above requirement I'm postulating to link all ports sharing the same file descriptor for the purposes of read buffer flushing, close() would only be called when the last port gets GCed.

- Harold