On 6/1/2024 7:56 am, Peter Dufault wrote:
>> On Jan 5, 2024, at 1:36 PM, Peter Dufault <dufa...@hda.com> wrote:
>>
>> I "#if 0"d out the call to "rtems_shell_term_row_column_swapped()" that
>> checks for a broken "tmux" terminal. That is what sends "\033[>0q" to the
>> console. I no longer see "0q" on the console but there is still a long
>> pause before the command is executed.
>>
>> Does it make sense to check the shell's terminal for its size before
>> executing every command? It could be checked once, or the check could be
>> moved into its own command. Now the shell checks for the terminal size and
>> if it is a "tmux" terminal before it calls every command.
>>
>> The escape sequence does work on gnome-terminal, so I'm not sure what causes
>> the delay. I can investigate that, but question if this
>> should be done in the shell.
>
> There's a bug detecting the timeout in rtems_shell_term_wait_for(). It does
> this:
>
> int msec = 150;
> while (msec-- > 0 && str[i] != '\0') {
> /* Do stuff. */
> if (nothing_arrived()) {
> usleep(1000);
> }
> }
>
> if (msec == 0) {
> /* BUG when we broke from the loop due to time out msec is -1, not 0. */
> }
>
> so if nothing comes in it treats it like it found a match, and for some
> reason nothing is coming in.
>
> The "telnetd01" test I'm running doesn't set CONFIGURE_MICROSECONDS_PER_TICK
> so I think the default is 10000 us. That means we call usleep(1000) 150
> times when no data arrives. If usleep() delays for one clock tick then that
> is 150 * .01 or 1.5 seconds. Since the code times out twice that's three
> seconds. Actually it used to timeout in 4.5 seconds before I disabled the
> call to rtems_shell_term_row_column_swapped() - that function is called even
> when the calls to get the lines and columns fails.
>
> I changed the code to use VTIME of 1 (1/10 second, or 100 msec) instead of 0.
> That lets TERMIOS do the character arrival timeout instead of using a delay
> in a loop that resets - essentially duplicating VTIME != 0 VMIN == 0. Once I
> did that it times out as I expect in .1 seconds.
Thanks for investigating this and finding a solution. Are you able to post a
patch?
> I don't know WHY no characters arrive but I know why it has a long delay.
The 150msec timeout is needed when accessing remote devices on the other side of
the world but it should be 1/10 of a second and then the shall moves on. The
process is only done when the command prompt is painted so it should not
normally be noticeable.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
