Yes, I agree. And by the same token we need to dup() the fd in port-fd, which I therefore have renamed port->fd. An advantage of duping is that if the existing Scheme mechanism already dups, all is well, and if it doesn't, it can be shimmed to do so. But if SRFI 170 specified not duping, then any duping implementations would be broken.

My only concern is running out of fds on systems with 10,000 ports (probably TCP ports) open, but that's a thing that can happen to anyone.

Once this and time objects are implemented, I think it's time for a second AND LAST last call.

On Sun, Sep 6, 2020 at 9:52 AM Shiro Kawai <xxxxxx@gmail.com> wrote:

Right, that seems the safest option. We did drop dup from the srfi but in this case we aren't exposing it.

On Sun, Sep 6, 2020 at 3:32 AM Duy Nguyen <xxxxxx@gmail.com> wrote:
On Tue, Aug 18, 2020 at 3:42 AM Shiro Kawai <xxxxxx@gmail.com> wrote:
>
> fd->*-port can't be implemented portably, so each implementation must work on it, interacting with its own port system. I'm not sure if a particular implementation has a difficulty to support either way.
> We don't need to worry about ports created by other means, so the implementation doesn't need to change their existing port handling.
>
> If we have implementations that already have native fd->*-port procedures, but some close fd automatically and others don't, then we have the compatibility problem and can't force either way. Is it the case? (Gauche has an optional argument to specify whether the port "owns" the fd or not; if the port owns it, closing port causes closing fd. So it can support either way.)
>
> Initially I thought a proper protocol ensures safe closure of ports and fds regardless of the port's ownership of fd

Can fd->*-port dup() the file descriptor instead of reusing and then
the port owns the new fd? Then a port can and must close its fd when
it's closed. The original fd is up to the user to manage. And the OS
is in charge of actually closing the in-kernel file object when all
associated fds are closed.
--
Duy