Re: [cdt-dev] [DSF] timeouts

[James Blackburn <jamesblackburn@xxxxxxxxx>]

On 23 June 2010 14:53, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:
> However, some calls are done within a synchronous DSF
> Query, and executed in the UI-thread.  If any of those
> don't complete, we are in trouble.  The Query class
> provides with a get(long timeout, TimeUnit unit)
> which we should probably use in those cases

If I understand this correctly, the above is very scary. Presumably
this is the cause of deadlocks like bug 314447 & bug 263689 where the
UI is waiting on a Query that never returns.

There's a golden rule in Eclipse: the user should never wait more than
0.1s for an action to complete/show progress on the UI thread[1]. Or,
alternatively, we should never spend more than 0.1s doing work on the
UI thread without processing user events. If we fail to obey this the
IDE feels laggy or worse.

In my experience with CDI over the last few years, is that while it
may lack some newer features, it doesn't lock up the IDE. And this is
really important.  It shouldn't matter whether the debugger loses a
connection to the target at a bad time, or I kill -9 gdb underneath
Eclipe's feet. I never want Eclipse to lock up as a result of
something going wrong externally.  And I do seem to have a fair hit
rate at locking up Eclipse while using DSF...

Presumably it's a goal for deadlocks and UI pauses in DSF to be
non-existent irrespective of the debugger stability and speed?
Shouldn't all debugger communication be down in a non-UI thread?

Cheers,
James
[1]http://www.eclipsecon.org/2004/EclipseCon_2004_TechnicalTrackPresentations/39_Arthorne-Lemieux.pdf