Re: [cdt-debug-dev] Remove timeouts in CDT?

["Alain Magloire" <alain@xxxxxxx>]

> 
> >I do not understand what must be fix in the CDT, if gdb stops responding
> >for x number of reason, what exactly do you propose ?
> 
> Kill the process.
> 
> CDT already has a tiny amount of native code per platform.
> 

As folks been saying, killing, is not necessarly the right action to take.
Sometimes gdb can recuparate and the session can still continue.
Killing 'til now was considered to be the last action and the kind of action
that only a user could take, not something that the CDT code should do
automatically because on commands timeout or exceptions, we would provoke lots of frustation,
if we decide to just kill gdb when things go wrong.

Our problem is that we do not know when gdb is __really__ stuck, so
the user who does know nothing about gdb is looking at a stale Debug view
cursing CDT and thinking it is flaky an unreliable.

> >> Assuming that CDT was changed to always be able to terminate a GDB
> >> session, would you agree that the timeout should be removed?
> >>=20
> >
> >it's not like we can do in Java
> >	signal(SIGKILL, 0);
> >On some system gdb does not respond, to events/signals.
> 
> If I understand you correctly, then it would be necessary to add a "kill pr=
> ocess"=20
> to the CDT native code library.=20
> 
> No big deal, or?
> 
> Using the "kill" command on Linux and even CygWin is an alternative to
> adding native code. How to launch the "kill" command would presumably be
> platform dependant.
> 

See above

> >Well there are 2 timeouts when launching and in normal operation.
> 
> If terminate worked always, it seems to me that both could be removed.
> 
> >On that subject there is a new Architecture that will be part of
> >Eclispe-3.1 that we intend to take full advantage of, please read:
> >
> >http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-debug-home/r3=
> _1/docs/concurrency/Concurrency-Debug.html?rev=3DHEAD&content-type=3Dtext/h=
> tml
> >
> >Altough I still think timeout will be a necessacity, to be able to
> >"bail out" from a long running operation.
> 
> I skimmed through it, but my understanding of the CDT innards isn't suffici=
> ent
> to properly connect the issues to the timeout discussion above.
> 
> 

We have timeout for many reasons, the first primary one was, in the old
eclipse version 1.x, 2.x and still 3.0.x in some degree:

the debug actions, like step/next or looking for the values of variables
were done in the UI thread.  So if for some reasons gdb will not answer
the entire IDE would be stuck ... not good.  So we introduce the timeout
and a complex threading mechanism(Tx thread, Rx thread etc ..) to be able
to "post" command to gdb and wait(timeout) for a response, so if the
command was done within the UI thread, we still could bail out in a timely manner.

So now we could just "pipelines" command to gdb and not wait for the answer.
If a command was required to be in synchronisation i.e. get the value of a
variable, the command could wait for a certain time, if no anwser it could just
"give up" and the user could try another time.

There are other problems with the MI/GDB protocol but we'll gloss over it 8-)
MI/GDB is still not purely event driven, but we should find time to solve
those issues with the FSF/GDB folks.

3.1 will introduce more concurrency meaning the actions will be done via jobs
and will never block the UI, reducing the need for the timeout mechanism.
This introduce other synchronisation problems that we will have to deal with
as we move along with 3.1.