[ECOS] gets() and task scheduling stopped

[Gary Thomas]

On Thu, 2002-01-10 at 14:17, Jonathan Larmour wrote:
> Gary Thomas wrote:
> > 
> > On Thu, 2002-01-10 at 12:34, Jonathan Larmour wrote:
> > > Sam Sortais wrote:
> > > >
> > > > >Sam Sortais wrote:
> > > > >[snip]
> > > > >> For what I understand with gdb it seems to
> > > > >> be stuck at the bottom of this
> > > > >> sequence of calls gets() -> refill_?() ->
> > > > >> read() -> readwrite() ->
> > > > >> dev_fo_read() -> cyg_io_read() -> tty_read() ->cyg_io_read() ->
> > > > >> serial_read() -> haldiag_getc() -> HAL_DIAG_READ->?
> > > > >> The scheduler is locked at many levels in
> > > > >> the previous calls. I was also
> > > > >> looking at a loop in tty_read() which is
> > > > >> done after a lock? but I do not
> > > > >> catch all the details of this low level
> > > > >> code.
> > >
> > > Looking at these functions I'm afraid I still haven't noticed where the
> > > scheduler gets locked. There are many places where a mutex gets locked, but
> > > not the entire scheduler.
> > 
> > If he's using RedBoot for the HAL diag channel, then both the scheduler
> > gets locked and interrupts are turned off while inside of RedBoot.
> 
> The call trace above implies this isn't the case (no mention of
> hal_if_diag_read_char), but of course this might be wrong. If it is wrong,
> that would indeed explain it.
> 
> I know it's a bit late, but I wonder if we should have defined
> CYGACC_COMM_IF_GETC_NONBLOCK instead of CYGACC_COMM_IF_GETC so the looping
> is done outside of the ROM monitor. Maybe we should, and switch to that?

Yes, that would help.  There would still be [short] periods where things
are turned off, but overall the system would keep running.