> From: Lassi Kortela <xxxxxx@lassi.io> > Date: Friday, August 09, 2019 2:42 AM >> [ John: ] >> 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. > [ Agreement, and comments on adding polling/select I/O scope. ] 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. In 3.5 Process state, do we keep pid? parent-pid goes, I think. (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? 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. In the TTY section, I gather none of open-control-tty, become-session-leader and control-tty-file-name stay. >> (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. That's a good argument, given how easy it is to add port or port/fd. 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. 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. > [ We agree truncate-file and file-info keep their port option. ] >> (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. 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. Will be moved. > [...] - Harold
