[MonoDevelop] Issues with the gui thread

[Lluis Sanchez]

On dl, 2004-09-20 at 16:28 -0700, Todd Berman wrote:
> On Mon, 2004-09-20 at 23:58 +0200, Lluis Sanchez wrote:

> >         
> > Of course, we could still use the traditional DispatchService methods,
> > but I think that those "artifacts" would be enough for most of
> > situations.
> > 
> 
> Yes. That sounds perfect.
> 
> We had begun to implement some stuff similar to that (Where public API
> was considered to be safe regardless of where it was called from), but
> didn't get anywhere near completion.
> 
> One thing to keep in mind, is some code will potentially have to be
> restructured.
> 
> When you dispatch something to the gui thread, you get execution back
> right away, potentially before the code has done what you needed it to
> do.

My idea is to add a synchronized dispatch, so the dispatch call won't
return until the method has finished its execution in the gui thread.
This isn't the most optimal solution for some cases, but it provides a
safe starting point. We can later optimize by reestructuring the code
and using asynchronous calls if needed.

> 
> Case in point:
> 
> When you double click on a method node in the class browser, it was
> calling OpenFile. OpenFile was changed to internally use
> DispatchService. However, the rest of the code in the event handler
> inside the class browser continued to run, and it attempted to operate
> on the 'newly' opened window, that wasn't actually open. These sorts of
> changes have to be watched for. Also, we are opening ourselves up to a
> very difficult to debug situation. While I agree that this is absolutely
> the right direction, debugging this new code will be far more difficult,
> as you wont get a stack trace beyond the most recent gui thread
> transition.

For synchronous calls this won't be such a problem because we can send
the exception back to the caller thread and get information from the
caller stack there. For asynchronous calls, we can do some tricks. For
example, we could capture the stack trace of the caller and show it if
the method call fails (this behavior would be enabled with a special
debug flag).

Lluis.