Re: linux native async mode support

[Vladimir Prus <ghost@cs.msu.su>]

On Saturday 05 April 2008 13:10:53 Nick Roberts wrote:
>  > > The helper functions that you have written for common sequences are a good
>  > > idea as they need only be updated in one place but the three here are the
>  > > only ones of their kind (they output an extra "^done" over MI commands like
>  > > -exec-next).  Not really worth a dedicated helper function do you agree?
>  > 
>  > Why there's extra "^done"? Presently, each command is supposed to have
>  > either "^running" or "^done", not both.
> 
> There's an extra "^done" because this is a CLI command entered in MI (and
> therfore case CLI_COMMAND: of captured_mi_execute_command).  There are many
> issues here like should we diallow immediate use of CLI commands now and
> require explicit use of "-interpreter-exec console"?

Probably not -- I don't see any immediate advantage from that.

> Then "-interpreter-exec 
> console next" doesn't emit "(gdb)/n" after "^running" when in asynchronous
> mode, so should we remove it from synchronous mode too (as you have suggested)?

This prompting is fairly confusing, so it could be that I've confused myself
as well, but I think "-interpreter-exec console next" actually *should* print
the prompt if the target is async-capable. The reason is that for MI mode,
we don't really care about terminal ownership issues, and then should not
care about sync_execution, and then this bit of code:

      else if (sync_execution)
	{
	  /* Don't print the prompt. We are executing the target in
	     synchronous mode.  */
	  args->action = EXECUTE_COMMAND_SUPPRESS_PROMPT;
	  return;
	}

in captured_mi_execute_command should be removed. In fact, I have a patch-in-progress
to do exactly that, and hopefully will be posting it later today.

> But these are all MI issues and this test is meant to just be a mark in the
> sand for asynchronous mode, and one that I had lying around.  For the moment, I
> don't really want to work on it further

Okay :-) Then, will you mind if I apply this patch either when I'm done with
another round of MI testsuite cleanups I'm doing today, or after the ^done is gone,
whichever proves more convenient?

>  > BTW, I'm not even sure that "^done" vs. "^running" + "^done" is so big
>  > difference that a helper function cannot be introduced.
> 
> The comment suggests that mi_gdb_test will not work but I have not revisited
> that since writing the test 18 months or so ago.  If true, that could also
> make helper functions difficult.

Do you happen to remember what race condition the comment mentions?

- Volodya