On Thu, Sep 10, 2020 at 11:05 PM Lassi Kortela <xxxxxx@lassi.io> wrote:
>
> >>> Why not combine open-file and
> >>> fd->*port in one? All other procedures either take pathname or a port.
> >>
> >> POSIX open() takes a whole bunch of flags which are relevant when
> >> opening a pathname and don't have much to do with converting an
> >> already-existing fd to a Scheme port.
> >> <https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html>
> >
> > So the new open-file also takes a bunch of flags and returns a port.
> > Since there's no way for you to get hold of an fd in the first place
> > (unless you count on special numbers 0, 1 and 2), converting an
> > already-existing fd to a Scheme port is a moot point.
>
> A child process using a known fd number (e.g. 3) from its parent (or
> from its predecessor before execve()) is a good convention for IPC.
> Hence it ought to be a useful feature to open a known fd as a Scheme port.

Yes. We can deal with that when we flesh out process management SRFI.
Until we know exactly the interface we have it may be premature to
introduce fd-based API.

> If some C API outside SRFI 170 returns an fd, being able to turn that
> into a Scheme port is also good.

I'm not concerned about FFI. If they can provide FFI, they can provide
wrappers to make a port out of it (and deal with fd management
themselves).

> If open-file takes an integer (giving the fd) how would it interpret its
> flags argument?

open-file (as the combination of an existing open-file and fd->*port)
just does not take a number, only paths.
--
Duy