bug#32986: 27.0.50; unexpected delay in while-no-input + accept-process-output

[Stefan Monnier]

>> I would expect while-no-input to break out of accept-process-output very
>> quickly after user keyboard input.  These expectations are met except
>> for some situations.
> I think your expectations are incorrect.

I beg to differ.

> My expectations are that if you call accept-process-output with
> a timeout of 30 sec, then while-no-input will return after 30 sec plus
> a small delay.

I'm OK if you don't consider it a "bug", but it does not satisfy the
needs behind `while-no-input`, so I think it's definitely something that
we should aim to improve.

The needs behind `while-no-input` often fail to be satisfied by our
C code, so this is not the first nor the last problem with it.
But if we can fix this case, Emacs will be better for it.

> First, one basic fact: accept-process-output calls
> wait_reading_process_output in a way that instructs it not to wait for
> keyboard input, you can see that clearly in the code (read_kbd is
> passed as zero).

What happens if we change this?

> This means that wait_reading_process_output will
> call pselect with the timeout of 30 sec (in your case), and will wait
> that long before it returns (unless there's a subprocess that gives us
> some stuff).  So why would you expect while-no-input that calls
> accept-process-output with that timeout to return earlier?

The question is not "given the current implementation, why should it
behave differently".  I expect it to return immediately because Emacs
is just there sitting idly so there is no good reason why it shouldn't
also check keyboard input at the same time as it's checking
process output.

> Therefore, to see the 30-sec delay, you need:
>
>   . stop all timers, which in "emacs -Q" means:
>     . disable blink-cursor-mode
>     . disable global-eldoc-mode
>     . disable font-lock-mode
>     . cancel the undo--auto-bindary-timer (I did that via list-timers)
>   . type "C-u C-x C-e", wait for a few seconds, and only then type SPC
>
> If I do all of the above, I see 30 sec plus a small delay every time I
> run your 2nd test.

IOW you cannot reliably expect it to wait 30s, so changing it so it
returns more promptly won't break any code.  That's good news.
All we need is for someone to come up with a patch.


        Stefan