RE: Is there a way to unset inferior-tty?

[Marc Khouzam <marc.khouzam@ericsson.com>]

> On 07/02/2016 03:04 PM, Marc Khouzam wrote:
> 
> > In the end I moved to a more complete solution for eclipse.   Right
> > after an inferior starts, eclipse will reset the tty to a new and
> > valid value; that way, if the user does a 'run', the tty will already
> > be properly set _and_ will direct inferior output to a valid eclipse
> > console.
> >
> > FWIW, this also led me to automatically set the tty for an inferior
> > that is created using the GDB console with the 'add-inferior' command
> > (thanks to the =thread-group-added event). I think this will make for
> > an improved user experience with the GDB console in eclipse.
> 
> Sounds to me like this will end up causing trouble.

Thanks for bringing this up.
I've been discussing your concerns with Simon, trying to find a possible
way forward.

> E.g., if you follow a big tree of processes (e.g., debug "make check"
> with "set detach-on-fork off"), you'll end up creating a useless tty
> for each of the thousands of short lived children spawned, right?

Right.  That's not good.  
In fact, even if the process is not short-lived, the forking scenario is
problematic because the child process will automatically use whatever
TTY has been used for its parent (IIUC, GDB couldn't change that, even
if it tried). So Eclipse would end up creating a useless extra TTY (as you 
mention), but could even end-up creating a user-visible console for that 
child process, even though the child process will be printing to the parent's
console.

It would seem sufficient, from a user point-of-view, to let the child re-use 
the parent's console.  We just have to make sure Eclipse is aware of that
somehow.  This may get addressed automatically by a possible solution
to your second point below.

> It's also racy.  E.g., a script can do:
> 
>  add-inferior ..
>  inferior 2
>  run
> 
> And before you managed to handle the =thread-group-added event,
> "run" has already run, so you can no longer change the inferior's
> tty.

This could even happen if the user simply copy/pasted the above 
commands into the GDB console in eclipse.
That's pretty bad, as we'd get inconsistent behaviour where sometimes
eclipse would create a new console for a new inferior and sometimes it
would not.

> Unless you're pointing all inferiors to the same tty?
> In that case, why are you destroying the original tty in
> the first place?

No, each inferior should get it's own tty so that we can handle different inputs
properly.  If I want to debug two, say, chat-clients, but that they share the
same tty, then their inputs channels will get confused.

> I wonder whether what we need is a "set default-inferior-tty TTY" command,
> that makes inferiors created with "add-inferior" inherit that
> TTY automatically?  With that, a frontend would have (or could give the
> user the) choice of making inferiors created in the console with
> add-inferior output to a separate console.  If that setting is clear,
> then output of new inferiors created on the console goes to
> gdb's console by default or to wherever the user forced with
> "set inferior-tty", just like when running gdb outside Eclipse.
> 
> In sum:
> 
>  #1 - If "set inferior-tty" is explicitly set in the inferior, use that.
>  #2 - Otherwise, if "set default-inferior-tty" is explicitly set, use that.
>  #3 - Otherwise, use gdb's tty.

"set default-inferior-tty" would nicely protect gdb's tty from inferior I/O,
so it would be an improvement.  However, it could still leave multiple
inferiors sharing the same tty for their different input streams.

If we want to have a different tty for each inferior but don't want to force
the user to provide it, Simon had the thought that GDB could
possibly create the new tty itself, for each new inferior,
and communicate it to eclipse in the =thread-group-started event.
GDB handling the tty creation would seem to be the only way to 
get past the race condition.

It would also take care of the forking issue, as GDB would tell
Eclipse that the tty used for the forked process was the same
as the tty of the parent.

Any thoughts on such an approach?