"My personal preference is to have a frozen UI since it forces developers to fix it fast."
I respect that from a developer point of view, but from a user point of view he is left with a "dead" product. User does not have too many patiences he may just stop using your product. Every product can fail, but it should fail gracefully and gives user
the reason so he can take appropriate action (like fixing the connection issue).
On 07/17/2012 11:19 AM, Andy Jin wrote:
Yeah, the UI needs to co-operate, for example outputs reasonable messages when timeout exceed, so that the degree of responsiveness is much better than a frozen UI.
My personal preference is to have a frozen UI since it forces developers to fix it fast.
My ignorance,
but why do we hang the UI while we are supposed to be a-synchronized?
There are still a few places where we don't have an async. API available. I mentioned cell editing and drag and drop in viewers, but there are others. GdbConnectCommand is not one of them though and should be fixed :-)
Thanks,
Andy
IMO, timeouts are a band-aid solution: do you really prefer a stuttering UI to a frozen one. I have to admit though sometimes even band-aids are useful ;-)
Cheers,
Pawel
On 07/17/2012 10:22 AM, Andy Jin wrote:
Some users report the debug session hangs the IDE. The stack trace is copied below. At that stage, "gdb" hangs for some unknown reason (that will be looked at separately), but the stack trace shows DSF GDB is waiting for gdb infinitely and that hangs the
main UI thread.
The org.eclipse.cdt.dsf.gdb.internal.ui.actions.GdbConnectCommand.canConnect() method sends the connect query using the org.eclipse.cdt.dsf.concurrent.Query.get() method. The "get()" method is blocked with no timeout. There is another "get(timeout, timeoutUnit)"
method but it is not used.
In fact, I see almost all DSF-GDB classes use the "get()" method, e.g. GdbLaunchDelegate. In the case when gdb hangs, those methods will block. Is there any reason we don't use the "get(timeout, timoutUnit)" method?
Thanks,
Andy
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/cdt-dev
|