4 ms·

A possible way of doing what you describe might be to add an extra file descriptor or two when invoking processes. Along side the normal stdin, stdout, and stde

by sime2009 6y ago

A possible way of doing what you describe might be to add an extra file descriptor or two when invoking processes. Along side the normal stdin, stdout, and stderr, you might have a couple more where a protocol can be used to negotiate and share typed data. It might even be possible to do it a backwards compatible way. (If in an app the extra file descriptors are missing, then fall back to old school stdin/stdout.) This blog from years ago describes something similar: http://acko.net/blog/on-termkit/ http://acko.net/blog/on-termkit/ i.e. expanding the process model

MayeulC 6y ago
Thank you for the blog post, it resonates quite well with me. I thought a bit about this, but that becomes a bit complicated without additional metadata on a file descriptor (is it really that additional interface, or just a random FD we inherited?). It might be possible to achieve in a robust way with mount namespaces and named pipes, but that's another can of worms... That said, it would likely work 90% of the time that way.
- sime2009 6y ago
  I pay attention to things in this area as I've been working a terminal which aims to do new and interesting things with text and also non-text datatypes. See "Shell integration" and below at https://extraterm.org/features.html https://extraterm.org/features.html Integrating some new shell projects like murex and nushell with Extraterm is on my TODO list.
- paulfurtado 6y ago
  I'd imagine that in a shell context, most of your FDs would be closed on exec unless explicitly passed. That said, why not use env vars which tell the child process what to expect on which file descriptor numbers? Depending how crazy you want to get, you could also use unix sockets to pass around FDs instead of inheritance. In that scenario, a process would be passed a unix socket either by a socket pair file descriptor or the shell would have a named socket which it tells child processes about using an env var. You can then use the sendfd functionality of unix sockets to pass around arbitrary file descriptors with arbitrary metadata. You could also use the unix socket to instead have the child process optionally ask the shell what the descriptor's metadata is. That way you'd keep backwards compatibility with unix tools, but the child process could sendfd the file descriptor back to its parent to ask for data about it. The parent could look it up by calling fstat on it and comparing the fstat data to the other file descriptors it sent to the child. But regardless, when you can't add a new syscall and need to do file descriptor stuff on behalf of another process, unix sockets + sendfd can really start to look like a userspace syscall interface which you can do a lot with.

MayeulC 6y ago

Thank you for the blog post, it resonates quite well with me. I thought a bit about this, but that becomes a bit complicated without additional metadata on a file descriptor (is it really that additional interface, or just a random FD we inherited?). It might be possible to achieve in a robust way with mount namespaces and named pipes, but that's another can of worms... That said, it would likely work 90% of the time that way.

sime2009 6y ago
I pay attention to things in this area as I've been working a terminal which aims to do new and interesting things with text and also non-text datatypes. See "Shell integration" and below at https://extraterm.org/features.html https://extraterm.org/features.html Integrating some new shell projects like murex and nushell with Extraterm is on my TODO list.
paulfurtado 6y ago
I'd imagine that in a shell context, most of your FDs would be closed on exec unless explicitly passed. That said, why not use env vars which tell the child process what to expect on which file descriptor numbers? Depending how crazy you want to get, you could also use unix sockets to pass around FDs instead of inheritance. In that scenario, a process would be passed a unix socket either by a socket pair file descriptor or the shell would have a named socket which it tells child processes about using an env var. You can then use the sendfd functionality of unix sockets to pass around arbitrary file descriptors with arbitrary metadata. You could also use the unix socket to instead have the child process optionally ask the shell what the descriptor's metadata is. That way you'd keep backwards compatibility with unix tools, but the child process could sendfd the file descriptor back to its parent to ask for data about it. The parent could look it up by calling fstat on it and comparing the fstat data to the other file descriptors it sent to the child. But regardless, when you can't add a new syscall and need to do file descriptor stuff on behalf of another process, unix sockets + sendfd can really start to look like a userspace syscall interface which you can do a lot with.