Hi Tim, Nicolas, One quick follow-up after my earlier mail: I've now finished the corresponding cleanup in the php-src PR as well.
Tim, I went through the implementation/test review comments and addressed the remaining points there. Nicolas, the shared raw-mode record and terminal identity changes are now in place too, including restoration through the record's own descriptor and keeping unrelated PTYs separate. The RFC text and the implementation should now describe the same lifetime/error semantics: https://wiki.php.net/rfc/io_terminal https://github.com/php/php-src/pull/23941 I also fixed the Linux PTY EIO test expectation on the current head. I don't want to keep adding noise to the list, so I'll leave it here unless I've missed something. Thanks again for the detailed review. Best, Pratik On Mon, 28 Sep 2026 15:00:09 +0200, Nicolas Grekas <[email protected]> wrote: > Hi Pratik, > > thanks for the RFC, PHP definitely needs native terminal support, calling > stty is a workaround we've been carrying since way too long. > > Le lun. 28 sept. 2026 à 11:49, Tim Düsterhus <[email protected]> a écrit : > > Hi > > On 2026-09-27 19:19, Pratik Bhujel wrote: > > > I would like to formally propose the Io\Terminal API for PHP 8.7: > > > > > > https://wiki.php.net/rfc/io_terminal > > Thank you for the RFC. Some questions to start of the discussion: > > 1. Should TerminalSize have a regular constructor? It seems to be safe > > to allow constructing it from userland, e.g. for testing purposes. > > 2. It would help readability if the stub would indicate the > > non-serializability (and strict properties) instead of mentioning it in > > the prose. Basically you can just take the stub file from your PR and > > include it in the RFC. > > 3. Terminal::create() should probably be ::fromStdio() or similar. > > 4. I'm not sure about false vs Exception for the various methods. > > `enableRawMode()` should probably be Exception, for `readKey()` the > > `false` return is not explained. Also the behavior of what happens when > > a timeout strikes is not explained. > > 5. Should ModeToken have a property that points back to the > > corresponding Terminal? Overall the interaction between the destructors > > and ModeToken and restoreMode should be explained more. As an example, > > what happens if the Terminal object dies before the ModeToken object? > > What if I create two Terminal objects for the same terminal? > > Related to ModeToken, what about a refcount instead? One record per terminal, > shared by all its tokens: the first enableRawMode() saves the original > termios and dup()s the fd into the record, the next ones only increment a > counter, and releasing any token decrements it. At zero, the original state > is restored through the record's own fd. That's order-independent by > construction and immune to fclose(). The RFC could then spec it in one > sentence: raw mode stays on as long as one token for that terminal is alive, > and the state from before the first token is restored when the last one goes > away. Today it says a token "restores its saved terminal mode when it is > destroyed", which isn't what happens out of order. If more modes are added > later, the record can keep the set of active requests and recompute the > target state from the original on each change. > > Cheers, > > Nicolas
