Re: RFA: Remove unused synchronous code

Re: RFA: Remove unused synchronous code

[Todd Whitesel]

> Not so fast.  There was some issue, I think related to stopping the
> inferior, that I reported shortly after the async loop as made the
> default.  I believe the fix was grotty enough that we (redback) were
> forced to go back to using the synchronous loop.
> 
> I'll try to look up the details sometime later today.

Whatever came of this?

FWIW the Wind River patches to GDB still use the sync loop, but only because
I have not gotten around to moving my command_loop/command_line_input patches
over to the async versions of those functions. I also have to ditch my async
patches for the official ones, but that's a separate issue.

Todd Whitesel
toddpw @ best.com

Re: RFA: Remove unused synchronous code

[Elena Zannoni]

Todd Whitesel writes:
 > > Not so fast.  There was some issue, I think related to stopping the
 > > inferior, that I reported shortly after the async loop as made the
 > > default.  I believe the fix was grotty enough that we (redback) were
 > > forced to go back to using the synchronous loop.
 > > 
 > > I'll try to look up the details sometime later today.
 > 

I missed this one somehow. Did JT post this?
Ok, one more argument to keep the code there a while longer.

 > Whatever came of this?
 > 
 > FWIW the Wind River patches to GDB still use the sync loop, but only because
 > I have not gotten around to moving my command_loop/command_line_input patches
 > over to the async versions of those functions. I also have to ditch my async
 > patches for the official ones, but that's a separate issue.
 > 

OK, so yes, it's still a little early to complete the migration to async.

Elena

 > Todd Whitesel
 > toddpw @ best.com
 > 

Re: RFA: Remove unused synchronous code

[Eli Zaretskii]

> From: Elena Zannoni <ezannoni@cygnus.com>
> Date: Wed, 21 Mar 2001 10:02:41 -0500 (EST)
> 
> Eli Zaretskii writes:
>  > 
>  > On Tue, 20 Mar 2001, Elena Zannoni wrote:
>  > 
>  > > Eli has a point.
>  > > I would like to close this issue and leave things as they are
>  > > for the 5.1 release. 
>  > 
>  > FYI: I have a known bug with using the async code in the DJGPP port.
>  > If you type quickly, sometimes characters get stuck in some buffer,
>  > and GDB becomes out of sync with user keystrokes; i.e. you type a key,
>  > but GDB sees the previous key.
> 
> Ah, thanks. I suspect there are a few (several?) bugs that still needs
> to be ironed out.
> 
>  > I don't yet know whether this is due to some bug in the DJGPP's
>  > version of `select' or something in GDB's own code.  It's the next
>  > issue I will be working on RSN, and I hope to get it solved for v5.1.
>  > 
> 
> Let me know if i can do something.
> Have you seen this anywhere else other than DJGPP?

I debugged this.  It's a bug in DJGPP's library (`select' wasn't
paying attention to characters buffered by the termios emulation).
After fixing it, the -async option is working correctly in the DJGPP
port.

Re: RFA: Remove unused synchronous code

[Elena Zannoni]

Eli Zaretskii writes:
 > > From: Elena Zannoni <ezannoni@cygnus.com>
 > > Date: Wed, 21 Mar 2001 10:02:41 -0500 (EST)
 > > 
 > > Eli Zaretskii writes:
 > >  > 
 > >  > On Tue, 20 Mar 2001, Elena Zannoni wrote:
 > >  > 
 > >  > > Eli has a point.
 > >  > > I would like to close this issue and leave things as they are
 > >  > > for the 5.1 release. 
 > >  > 
 > >  > FYI: I have a known bug with using the async code in the DJGPP port.
 > >  > If you type quickly, sometimes characters get stuck in some buffer,
 > >  > and GDB becomes out of sync with user keystrokes; i.e. you type a key,
 > >  > but GDB sees the previous key.
 > > 
 > > Ah, thanks. I suspect there are a few (several?) bugs that still needs
 > > to be ironed out.
 > > 
 > >  > I don't yet know whether this is due to some bug in the DJGPP's
 > >  > version of `select' or something in GDB's own code.  It's the next
 > >  > issue I will be working on RSN, and I hope to get it solved for v5.1.
 > >  > 
 > > 
 > > Let me know if i can do something.
 > > Have you seen this anywhere else other than DJGPP?
 > 
 > I debugged this.  It's a bug in DJGPP's library (`select' wasn't
 > paying attention to characters buffered by the termios emulation).
 > After fixing it, the -async option is working correctly in the DJGPP
 > port.
 > 

Ah, Great!

Thanks

Elena

Re: RFA: Remove unused synchronous code

[Elena Zannoni]

Hi, I am going through a list of pending e-mails. 
(yes, I have been out of the loop for a while.)

Eli has a point.
I would like to close this issue and leave things as they are
for the 5.1 release. 
We should revisit this after 5.1 is out/branched.

OK?
Andrew?

Thanks
Elena 


Eli Zaretskii writes:
 > > Date: Fri, 01 Dec 2000 16:30:05 -0500
 > > From: Fernando Nasser <fnasser@cygnus.com>
 > > 
 > > The new event loop has been the default since 1999-06-23.  This is
 > > almost 1 1/2 yrs.
 > 
 > I don't think it's correct to measure time since the introduction of
 > the feature into the CVS.  I think we need to measure since the first
 > official release which made it the default, since that's when the
 > users really see it.
 > 
 > Correct me if I'm wrong, but I think that GDB 5.0 was the first
 > official release that used the event loop as the default.  GDB 5.0 was
 > released in May 2000, which is only 6 months ago.
 > 
 > In addition, DJGPP users only got a precompiled binary a few weeks
 > ago (my fault), so they only now begin using it en masse.
 > 
 > I think that removing the fallback after a single release is a too
 > short notice.  I think we should keep it for at least one more
 > version.  Please keep in mind that the async code is modeled on Unix
 > and GNU/Linux systems; other platforms are using emulations of
 > `select' and related facilities, and the quality of those emulations
 > might vary...
 > 
 > > It happens that the provisions for fall-back (run synchronously) are
 > > getting in the way, making the code illegible
 > 
 > Perhaps we could discuss the specific problems with retaining the old
 > code, and find interim solutions for them that won't require excessive
 > labor.
 > 
 > > and requiring
 > > duplicate efforts (you should still make sure that the old way works
 > > -- have you tested with --noasync after applying your patches?).
 > 
 > Perhaps the test suite should be run with --noasync as well as without
 > it?

Re: RFA: Remove unused synchronous code

[Fernando Nasser]

Elena Zannoni wrote:
> 
> Hi, I am going through a list of pending e-mails.
> (yes, I have been out of the loop for a while.)
> 
> Eli has a point.
> I would like to close this issue and leave things as they are
> for the 5.1 release.
> We should revisit this after 5.1 is out/branched.
> 

I would like to have a decision to remove it right after the branch, as
we remove the pre-ui-out code.  We have already seem a few instances of
fixes/changes being applied to only one version of the code (this on the
ui-out/non-ui-out case -- the non-async is probably stale as async has
been the default for so long)..

Fernando


> OK?
> Andrew?
> 
> Thanks
> Elena
> 
> Eli Zaretskii writes:
>  > > Date: Fri, 01 Dec 2000 16:30:05 -0500
>  > > From: Fernando Nasser <fnasser@cygnus.com>
>  > >
>  > > The new event loop has been the default since 1999-06-23.  This is
>  > > almost 1 1/2 yrs.
>  >
>  > I don't think it's correct to measure time since the introduction of
>  > the feature into the CVS.  I think we need to measure since the first
>  > official release which made it the default, since that's when the
>  > users really see it.
>  >
>  > Correct me if I'm wrong, but I think that GDB 5.0 was the first
>  > official release that used the event loop as the default.  GDB 5.0 was
>  > released in May 2000, which is only 6 months ago.
>  >
>  > In addition, DJGPP users only got a precompiled binary a few weeks
>  > ago (my fault), so they only now begin using it en masse.
>  >
>  > I think that removing the fallback after a single release is a too
>  > short notice.  I think we should keep it for at least one more
>  > version.  Please keep in mind that the async code is modeled on Unix
>  > and GNU/Linux systems; other platforms are using emulations of
>  > `select' and related facilities, and the quality of those emulations
>  > might vary...
>  >
>  > > It happens that the provisions for fall-back (run synchronously) are
>  > > getting in the way, making the code illegible
>  >
>  > Perhaps we could discuss the specific problems with retaining the old
>  > code, and find interim solutions for them that won't require excessive
>  > labor.
>  >
>  > > and requiring
>  > > duplicate efforts (you should still make sure that the old way works
>  > > -- have you tested with --noasync after applying your patches?).
>  >
>  > Perhaps the test suite should be run with --noasync as well as without
>  > it?

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9