Move debugger on a separate thread

[dgrunwald]

SD-1491, originally created on 12/21/2008 22:06:14 by Daniel Grunwald

Debugger commands should be executed in a separate thread (not on the
GUI thread) to improve performance (e.g. for Debug.WriteLine) and to
allow moving the debugger into a separate process (e.g. on 64-bit
Windows).

[dgrunwald]

We discussed some approaches to this issue on the last meeting in Ischl (in 2013).
We did not decide on a way forward. However, we were strongly considering to move to MonoDevelop's debugger API.
Unfortunately, it seems like that doesn't directly solve all of our problems:

• MD.Debugger supports remote debugging for Mono, but AFAIK not for .NET (ICorDebug).
• MD.Debugger creates the ICorDebug objects in an MTA. SharpDevelop uses the UI thread's STA. Here, the MonoDevelop approach is better for moving the debugger to another process.
• The MD.Debugger API looks weird, exposing internal objects used by the backend engine (such as the ICorDebug COM objects) as untyped object return types, and expecting them back as parameters in other API calls.
• Passing said internal, non-serializable objects through the API means we can't easily use the MD API itself as a remoting layer.
• We use the NRefactory type system in the SharpDevelop 5 debugger, and would like to keep doing so. The MD debugger API has its own minimal type system (based on those objects).
• Some ICorDebug features such as SetInstructionPointer are not supported by the Mono runtime, and not exposed in the MD debugger API.
• Using an existing, maintained code base means we don't have to fix all the bugs ourselves.