Re: [cdt-dev] [DSF] timeouts

[John Cortell <rat042@xxxxxxxxxxxxx>]

I think that's a very accurate dissection of the issue.

The challenge to specifying a timeout is equally present in MI and 
DSF, though. Generally speaking it's no more easier predicting a 
reasonable timeout for an MI command as it is for a DSF operation. 
You're trying to get the list of local variables. How much patience 
should you have for that? Does the answer really matter all that much 
if the locals are being queried via gdb/mi or some other backend API? 
The answer is much  more likely to vary based on other factors (local 
vs remote debugging and debugger engine load, e.g.). So, one needs to 
wonder if pushing the burden down to the backend accomplishes 
anything other than keeping DSF cleaner.

I'm not arguing for any particular solution. I think this is a very 
tricky matter and one that is unlikely to have a solution everyone 
will be very happy with.

John

At 10:17 AM 6/23/2010, Pawel Piech wrote:
> There are two issues here:
> 1) Should there be a timeout mechanism for MI commands that do not 
> complete in a timely fashion.
> 2) Fault tolerance for asynchronous calls not being completed due to 
> programming errors.
>
> For first issue a timeout seems like an appropriate solution.  The 
> timeout could be specified at command creation and handled by the 
> command control service.  In other cases a timeout at the query may 
> be appropriate as well.
> For the second issue we definitely need some improvement, though I'm 
> not sure if timeouts are an appropriate solution.  The problem with 
> timeout is that you have to specify a timeout value that is large 
> enough that it won't get triggered accidentally on a heavily loaded 
> systems, but small enough that it won't appear as if the UI was 
> hanging.  Another option to add fault tolerance for async calls 
> would be to instrument the DSF executor better to detect when a 
> request monitor is being orphaned due to a runtime exception.  This 
> wouldn't be a complete fix, but it would probably cover most of the 
> cases of uncompleted async. calls we see now.  Finally the best way 
> to add fault tolerance is to improve the automated testing ;-)
>
> Cheers,
> Pawel
>
> On 06/23/2010 06:53 AM, Marc Khouzam wrote:
> > Yes, I'm starting to be concerned about our lack
> > of 'timeout' support.
> >
> > This is a question for DSF in general I believe.
> >
> > Currently, most calls are asynchronous and are left to
> > complete whenever they do, if at all.
> >
> > 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.
> >
> > Outside those UI-thread cases, I believe we could
> > still hang a view if a command never complete and
> > the update.done() is never called.  Isn't that the case?
> >
> > Marc
> >
> >
> >
> > > -----Original Message-----
> > > From: cdt-dev-bounces@xxxxxxxxxxx
> > > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
> > > Sent: Wednesday, June 23, 2010 8:11 AM
> > > To: CDT General developers list.; 'cdt-dev@xxxxxxxxxxx'
> > > Subject: Re: [cdt-dev] [DSF] timeouts
> > >
> > > See
> > >
> > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=310274#c23
> > >
> > > This is a discussion we tabled until after Helios. Maybe now is a
> > > good time to return to it.
> > >
> > > John
> > >
> > > At 04:53 AM 6/23/2010, Vladimir Prus wrote:
> > >
> > >
> > > > Does DSF have a mechanism to timeout when a command takes too much
> > > > time? One case I've run into right now is failure to call done on
> > > > a request monitor. Another viable case is when a target is stuck
> > > > for whatever reason. I could not find any provisious for marking
> > > > an operation failed after a while -- have I missed something?
> > > >
> > > > Thanks,
> > > >
> > > > --
> > > > Vladimir Prus
> > > > CodeSourcery
> > > > vladimir@xxxxxxxxxxxxxxxx
> > > > (650) 331-3385 x722
> > > > _______________________________________________
> > > > cdt-dev mailing list
> > > > cdt-dev@xxxxxxxxxxx
> > > > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > >
> > > _______________________________________________
> > > cdt-dev mailing list
> > > cdt-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev