Re: A whole lotta auto-saving going

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  aaronjensen@gmail.com,
>   emacs-devel@gnu.org
> Date: Sun, 10 Jan 2021 23:23:23 -0500
> 
> Apparently, the early exit from `wait_reading_process_output` comes from
> the following `break`:
> 
>           if (!process_skipped && got_some_output > 0
>               && (timeout.tv_sec > 0 || timeout.tv_nsec > 0))
>             {
>               if (!timespec_valid_p (got_output_end_time))
>                 break;
> 
> Does someone here understanding something of what
> `wait_reading_process_output` does and what it is expected to do?

You mean, in general? or in this specific case?

The latter is described by the comment above this fragment.

> Why does it exit here before the end of the timeout?  IIUC it is
> supposed to exit as soon as we got some output from `wait_proc`, but in
> this case `wait_proc` is NULL.  Is it also supposed to exit when some
> process output arrives?  If so, shouldn't `sit_for` wrap the call to
> `wait_reading_process_output` inside a loop to make sure we wait the
> whole timeout?

I think sitting for the entire period is undesirable, since receiving
output from a process might require redisplay.  In that case, waiting
could make Emacs seem unresponsive or busy, whereas it really isn't.

I think a simple solution to this would be to check the time passed
after sit_for returns, and if some of the wait time is left, not call
auto-save.  This would mimic what happened before the offending
changeset.

We could, of course, add a loop inside sit_for, but that function is
called in a few other places, and even in this place it isn't certain
that we never want it to return early upon receiving process output.
So, while adding a loop, and then dealing with whatever further
breakage this will cause could be an exciting project, I'm not sure we
are looking for such an excitement.  One cleanup at a time, okay?