A Friday 14 March 2008 19:18:21, Daniel Jacobowitz wrote:
> Could you do some refactoring on this, please?  It duplicates code
> from attach_command.  When I fixed up step last year I moved the
> common code into its own function.  Makes it much easier to see
> the differences between async and sync operation.  And for instance
> it lets me see that you're calling deprecated_attach_hook twice
> in async mode :-)

I don't think I was :-)  There were three different exit points.
sync, async/sync_execution, and true async.  I've reverted the
bits that immediatelly proceed after attaching, and defered it
to the continuation (for the attach& support).  I'll look
into short-circuiting that again when non-stop is in.  The
attach& mode is still supported, but we wait for everything to
be stopped and stable before deciding to proceed or normal_stop.

This is look alright?

Tested on x86_64-unknown-linux-gnu with the linux async
support (new patch follows) enabled and disabled.

-- 
Pedro Alves

(P.S. Am I the only one that thinks that continuation
arguments suck?  IMHO, we should move the continuation_arg data
union into the continuation proper, and force people to use
structs for the compound args.  Oh, and who is responsible for
freeing the continuation args?  Nobody seems to be doing that.)