|Re: [cdt-dev] [DSF] timeouts|
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 casesIf 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. 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 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
Back to the top