Anthony Hannan wrote:

> Hans-Martin Mosner <hmm at heeg.de> wrote:
> > It might be possible to further modify the quickStep mechanism so that it
> > runs in the process being debugged.
>
> I do this in the BC version by inserting an ensure: method context under
> the context to be executed.  Then I resume the debugged process and wait
> on a semaphore.  The unwind block of the ensure: context signals the
> semaphore when reached, meaning that the context above it has finished
> and the debugger can take over again.  I also insert a on:do: method
> context above the ensure: method context in case any errors are raised.
> The handler block signals the semaphore so the error can be shown in the
> existing debugger.  In either case when the parent process is resumed I
> remove the contexts I added so you don't see them in the debugger.  See
> #runUntil:suppressDebugger: in the BC version for the implementation.

That's what I was dreaming of. Good that you already have it! Alay, I haven't
had time yet to look into the BC stuff :-(

> Also, here is another argument for 'thisContext process' over 'Processor
> activeProcess'.  The former will be needed when we (someday in the
> future I hope) have multiple processes running simultaneously on
> multi-processor machines.  In this case, 'Processor activeProcess' would
> be ambiguous.

Well, Processor activeContext could be a primitive which does the right thing,
but you're right it's much easier to do from thisContext in your
implementation. And I do think that the current context is the right object to
ask about the process in which it executes, and not some stupid global which
happens to manage processes by dirty VM magic :-)

Cheers,
Hans-Martin