> I am now firmly of opinion that we should remove all the process-related
> functions from SRFI 170 along the lines you specified earlier, whatever
> we decide to do about processes in a future SRFI.  I have some general
> ideas, but they are stll completely unformed.

It may be that processes, signals and select/poll should all go into the
same SRFI. It sounds like overreaching, but when you think things
through, those are really intertwined and hard to separate without
introducing copious amounts of Undefined Behavior. Marc's comments about
the I/O system in Gambit, and discussions we had with Göran about signal
handling, factor heavily into this.

We should carefully study Gambit's I/O multiplexing as well as the libuv
C library (<https://en.wikipedia.org/wiki/Libuv>) before making any
decisions. We should check out what Chicken is doing too for good
measure (actually I promised to write them a patch that will use
Chicken's internal poller, so I can look into it).

I'll have to study and explore for some days to have a better grasp of
these things.

>     |(set-file-mode/fname/port mode-bits/)|
>     |(set-file-owner/fname/port uid/)|
>     |(set-file-group/fname/port gid/)|
>     |(set-file-timespecs/fname/port [access-timespec modify-timespec]/)|
>
> I say: Switch all these to filenames only.  You shouldn't be changing
> these things for a file whose identity you dont know

The point of these syscalls (fchmod, fchown, fchdir, etc.) is to use
them in situations where you opened a known file. Using the fd instead
of the path prevents things like having a directory disappear from
underneath you during the lifetime of the process if that directory's
path is renamed.

>     |(truncate-file/fname/port len/)|
>     |(file-info/fname/port/)|
>
> These are in fact paired: truncate() for files, ftruncate() for fds;
> stat() for files, fstat() for ports.  Both are useful.  Indeed stat()
> cannot be implemented with fstat(), because if you can't open() the file
> you can't fstat() it.  So I say:  Retain the fname/port duality for these.

Agreed.

>     |(tty-process-group/port/fname/)|
>     |(set-tty-process-group/port/fname process-group/)|
>
> These go with the process stuff, so no need to decide yet (see above).

Or with the TTY stuff.

> The FileAdvancedCowan pre-SRFI supports lseek under its R6RS name of
> get-file-position and set-file-position!

I see you also have (make-pipe), (select-ports) and
(select-port-channels) in there. My current hunch is that those would go
best in whichever document specifies the polling framework as a whole,
and absent from other documents. But this may change.