Re: linux native async mode support

[Pedro Alves <pedro at codesourcery dot com>]

A Friday 14 March 2008 23:09:51, Nick wrote:
> Wow!

:-)

> It seems unfortunate that you had to move async_file_handler into
> linux_nat.c as much of this seems generic and will presumably make it
> harder to port the async mode to other platforms.  I put it in inf-ptrace.c
> (*) which creates problems if the target doesn't actually support async
> mode.  More recently I thought maybe not setting t->to_async_mask_value to
> 1 in inf_ptrace_target might solve that.
>

On the contraire.  Not assuming abstractions upfront allows us to
enhance and test the linux port, without worrying about the other
inf-ptrace.c clients breaking.  We'll add the non-stop support soon, and
that will need further tweaking.  We can worry about abstractions and
common code when someone wants to add async support to another target.
I'd advise to hold on a bit until we stabilize this port a bit more.

> Daniel talks about async mode being the default but I don't really
> understand this.  In order for Gdb to be able to accept input while the
> inferior is running and possibly accepting it's own input, seems to require
> separate terminals.  This isn't a problem for a front end but, in general,
> will be when Gdb is run from the command line.

This is a confusion of terms.  The async mode he was refering to, is
the event loop code path, in which we (ideally) never block in
wait_for_inferior.

I'm sure you know most of this already, but let me repeat it for
clarity.

If the target supports async event loop mode, the user can still run
the inferior in synchronous mode, with the usual commands, and
gdb can put the inferior in the foreground.  That's currently
controlled by the sync_execution global variable.  The sync_execution
mode is implemented on top of the async/event loop code path, and can
(ideally) be ignored by the target code (as long as it supports
async/event loop mode).  It is up to gdb common code to disable
stdin to simulate synchronous execution, which enables passing
the terminal to the inferior.  From a users perpective, target
in event loop mode with sync_execution set is the same as
what we have had until now.

In addition to that mode, by having the target in async/event loop
mode, the user/frontend can use the background execution commands
(run&, continue&, step&, etc.), which makes gdb accept input
from the user/frontend while the inferior is running.  This is
essential for non-stop mode, which we'll be adding soon.

In a nutshell, having the target in "async mode" has no
drawbacks, only advantages.  It's only that it isn't perfect yet.  When
we get to the point where the non-async code path is not needed anymore,
we can drop a bunch of support code.  That's doesn't seem likelly to
happen anytime soon in the common code, but it can be done target by
target.  Linux native and target (extended-)remote are the first
candidates.

(I'll address the patch comments later)

Thanks!

-- 
Pedro Alves