Date: Monday, September 07, 2020 3:09 PM
Unless it is decided to rename or hide port-real-fd.
I don't see that it's very useful for anything. What would you do with it? The only SRFI 170 procedures that accept fds are close-fd and fd->*port, and only open-file returns one. So you'd typically call open-file, pass the fd to fd->port, and then call close-fd. If you know that some fd is in use when you start up, then fd->port and close-fd would be the thing. But if you need to leave the fd open in your child processes, call fd->port only.
The utility is if you want to do non- or not completely SRFI 170 things with the fd after getting it, and not a dup()ed copy of it, the whole "used at the edges" concept. Also if there's any chance it'll be needed in future POSIX SRFIs, seeing as how it's a required internal function, I'm only proposing to not hide it.
Anyone out there, can you think of any specific use cases for it, where the dup()ed port->fd procedure would not suffice?
- Harold