Jeff King <p...@peff.net> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html