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