[
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.
Cheers,
Pawel
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?
Cheers,
James
[1]http://www.eclipsecon.org/2004/EclipseCon_2004_TechnicalTrackPresentations/39_Arthorne-Lemieux.pdf
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
