Re: How attached are we to taking a port (or port/fd) as well as a filename? Lassi Kortela 09 Aug 2019 07:42 UTC
> 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.