Jeff King <peff@xxxxxxxx> writes: > Erik has looked into doing a Windows alternative in compat/terminal.c, > and I think an integer would be insufficient there. In particular, I > think Windows needs two descriptors to accomplish the same thing (one > for CONIN$ and one for CONOUT$). So you'd need to turn term_t into a > struct (and you'd probably not want to return it by value then). > > Maybe it would be better to keep the abstraction as non-leaky as > possible, and just provide "terminal_can_prompt()" or similar? OK. As we won't be giving separate instances of terminals to different callers anyway, compat/terminal.c can keep a static variable of whatever type that is necessary for the implementation around. That sounds like a reasonable way to go. > Returning the open descriptor (as Tay's patch does) avoids a race > condition where /dev/tty can be opened when terminal_can_prompt runs, > but not when we try to actually read from it. But we can either: > > 1. Not care. Even if the tty is opened, if a user has closed the > terminal we are going to get a read error anyway. So you can never > avoid that race condition in some form. > > 2. Open the terminal descriptor when either function is called, and > never close it. I don't think there is any reason we can't just > leak the descriptor. > > -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html