On Fri, Aug 9, 2019 at 3:42 AM Lassi Kortela <xxxxxx@lassi.io> wrote:

It may be that processes, signals and select/poll should all go into the
same SRFI.

I agree about processes and signals, but not select, which has nothing to do with the management of external processes.

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. 

In order to support threads (and I assume R7RS-large will have threads or possibly futures), there needs to be an I/O multiplexer in the implementation anyway.  My futures pre-SRFI at <https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/FuturesCowan.md> explicitly says: "When a future invokes a blocking I/O operation, the implementation must ensure that only that specific future is blocked and that all other futures continue to run.  [...] An implementation may depart from this requirement but must document its exact limitations."  Although SRFI 18 has no similar statement, all implementations that I know of behave this way.  Anything else would be un-Schemey.

Given that, surfacing something like select to the user is a no-brainer.
 
> You shouldn't be changing [mode, owner, etc.] 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.

I see the force of that, but I don't think it meets the 80/20 rule.  These were file-only for a looooong time before their fd equivalents were introduced, and "when in doubt, leave it out".   I'm open to being convinced otherwise, though.

>     |(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.

No, they don't matter if you aren't manipulating process groups.
 
I see you also have (make-pipe), (select-ports) and
(select-port-channels) in there.

Yes.  I moved them out because they make the most sense on ports.  See above for the justification. 



On Fri, Aug 9, 2019 at 8:52 AM <xxxxxx@ancell-ent.com> wrote:

I'll work on that next, forwarding to the list anything where I'm not
sure.  Right now that includes dup->fdes, as I understand it, dup and
dup2 are only needed in the context of forking.

Agreed.
 
In 3.5 Process state, do we keep pid?  parent-pid goes, I think.

Yes to both.  Pid is important for logging, temp files, etc.
 
(priority which who) gets reduced to a no argument call of the current
process and the priority/process option.  For the sake of simplicity
in the SRFI, perhaps keep only one of set-priority or nice?

Nice is the important one: it's meant to be set by the process to indicate its own degree of humility.  Priority is the actual kernel priority and is only a nice-to-have.  Let's drop it.
 
Do you ever want to send a signal to yourself??  Hmmm, you do if you
want to test your signal handling code in a standardized way.

Signal handling is out of scope as of now, and I think it should stay there.  Individual things may need to handle SIGC(H)LD or SIGWINSIZ, but that can be done at the implementation level.
 
In the TTY section, I gather none of open-control-tty,
become-session-leader and control-tty-file-name stay.

Remove them.  Control-tty-file-name is useful if you don't have a fd to your terminal and want one (to prompt for something, e.g.), but as the scsh manual says, plain "/dev/tty" works pretty much everywhere.
 
That's a good argument, given how easy it is to add port or port/fd.

Ease of coding isn't really an argument; that encourages bloat.
 
Let me ask explicitly, do we want these instances of filename/port to
become filename/port/fd?  Only adds a little more logic in argument
parsing, but every bit counts.

It counts even more in documentation and in understanding than in coding.
 
  I think no, for I suspect it only
makes sense to convert to ports as soon as you surface back to Scheme
from any C/FFI code you might be writing.

Agreed. "Fds only at the edges."
 
Both, it's in the TTY section, but I gather only make sense in the
context of multiple processes, whereas line discipline stuff, however
we do it, belongs in this SRFI.

Minimally.  I like my just-three-procedures version, which is what's needed to write full-fledged CLIs.  TUIs should use the character grid model.
 


John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
If [Tim Berners-Lee] has seen farther than others,
        it is because he is standing on a stack of dwarves.  --Mike Champion