Re: HAVE_POLL is not enough

[Elena Zannoni <ezannoni at cygnus dot com>]

Philippe De Muyter writes:
 > First of all, sorry for the long delay for answers, but I am really busy
 > (and more) with my day-hours work.
 > 
 > > Elena Zannoni wrote:
 > > > 
 > > > Philippe De Muyter writes:
 > > >  > With the gdb cvs tree of 2000-02-19, on m68k-motorola-sys, configure
 > > >  > correctly detect  that we have `poll', but gdb incorrectly assumes that
 > > >  > `poll' can be used to wait for `stdin'.  On m68k-motorola-sysv, tty's
 > > >  > are not stream-based and not `poll'able.  Should the configure test
 > > >  > be enhanced ? I don't think so if we need to run a target program to check
 > > >  > that, because it would fail if we cross-compile gdb, but if it can be
 > > >  > determined by other ways, like the presence of some constants in some
 > > >  > header files then I would agree.  We could also always compile in the `poll'
 > > >  > version if HAVE_POLL, but switch to the the fall-back method at run time if
 > > >  > poll fails with POLLNVAL.
 > > >  >
 > > > 
 > > > Right now the decision on whether to run gdb with or without the event
 > > > loop is determined by the user as start up, and it is not detected
 > > > neither by configure or at run time. The easiest thing to do for now
 > 
 > I did not ask explicitly to start gdb with or without the event-loop, and it
 > tried automatically to use the event-loop.  I don't know why but that seems
 > to invalidate Elena's statement that `it is determined by the user as start up'.
 > 

Sorry, that was unclear, there is a --noasync switch you can start up
gdb with and that will not use the event loop, but the old command
loop. (assuming it hasn't suffered from bitrot). 

Elena

 > > > is probably tell the user what happened and switch to
 > > > non-event-loop mode.  Maybe some configury work could be done to
 > > > determine whether the tty's can be pollable, I am not familiar with
 > > > your system enough to know whether this is anything feasible.  Sorry I
 > > > cannot be of more help here.
 > > > How about the 'target async' part, would that work?
 > > 
 > > As far as I know, this problem is still present.
 > > 
 > > Following on from Elena's comment.  Is there any known work around or
 > > other hack available?
 > > 
 > > If we get really desparate there is always the option of putting:
 > > 
 > > 	HOST_POLL_BROKEN
 > > 
 > > in
 > > 
 > > 	config/m68k/xm-m68kv4.h
 > > 
 > > :-( (And yes, I'm about to get really desperate).
 > > 
 > > Philippe, if GDB is forced to use select, does it work?
 > 
 > If we never use poll, and always use select if it is available, I think
 > we'll then have the inverse problem : platforms where some channels are
 > `poll'-able, but not `select'-able.
 >
 > So, my idea is : at gdb startup, first poll the needed fd's one by one with
 > a null or small timeout, and if one is not `poll'-able, then switch to `select'.
 > I know that on m68k-motorola-sysv, `stdin' is `select'-able, so this scheme
 > would work.
 > 
 > Sorry, no time for a patch at the moment.
 > 
 > > 
 > > 	Andrew
 > > 
 >