[MonoDevelop] Issues with the gui thread

[Todd Berman]

On Tue, 2004-09-21 at 16:51 +0200, Lluis Sanchez wrote:
> 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.
> 


Excellent

> > 
> > 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).
> 

That sounds perfect. I just wanted to make sure we aren't deep down this
path before we realize debugging is next to impossible (evolution).

--Todd