Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] [DSF] timeouts

Blocking the UI thread to make a thread switch is a last resort, though there are a few places where this currently unavoidable. The most common one is cell editing in a tree table and drag and drop operations. Getting rid of these would require jface or swt changes. In practice though I haven't seen any instances of deadlocks or even visible UI slow-down resulting from these. That's because in practice the related data is always cached already. If people do find issue with it, the UI could be made smarter to only allow you to cell-edit or DND elements which are cached already.

For other instances I'm guessing that we could get rid of though it would probably take a pretty significant amount of effort. The one that got a lot of hits this year was implementation of the synchronous java.lang.Process.exitValue(). This one does in fact go out to gdb to collect the exit value. The use of Process object and its wrapper IProcess could be eliminated completely, though it would be a lot of work.

Finally, I think all the deadlocks we've observed during Helios were results of programming errors in the implementation of the async. methods. Making DSF more fault tolerant would help, but IMO better automated testing would help more.


On 06/23/2010 02:01 PM, James Blackburn wrote:
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?

cdt-dev mailing list

Back to the top