Re: Nested sit-for's

[storm@cua.dk (Kim F. Storm)]

Richard Stallman <rms@gnu.org> writes:

>     >> What about the change that we discussed where nested sit-for calls
>     >> should not wait longer than any of the outer calls??
>
> I am not sure it is really a bug.  Whether this behavior is incorrect
> depends on how you think of sit-for's purpose, and there is a natural
> way to think of it which makes this behavior correct.  For the inner
> sit-for fail to wait for the time specified seems clearly wrong.
>
> My conclusion is that it is wrong for a timer to do a sit-for that
> lasts any substantial time.  It should instead schedule a new timer.
> As long as jit-lock-stealth-nice is a short period such as 0.5, its
> sit-for cannot cause a big delay to anything else.
>
> The potential problem I do see is that jit-lock-stealth-fontify will
> keep looping as long as input-pending-p is nil.  If it were to run
> from inside some other idle timer, that other idle timer would not get
> control back until fontification is finished.  Making
> jit-lock-stealth-fontify's sit-for return faster won't avoid this
> problem, only reduce it, since jit-lock-stealth-fontify still would
> not return until it finishes fontification.  The only solutions are
> (1) that jit-lock-stealth-fontify reschedule itself instead of using
> sit-for, or (2) that the other timer function avoid using sit-for.

> If several timers try this sit-for trick, then no matter what we make
> sit-for do, they can't all get the behavior they want, which is to do
> some more processing at a certain time in the future.  The only method
> they can all use that enables them all to get this behavior is that of
> rescheduling timers.
>
> It would work to have ONE timer that does sit-for if we make a rule
> that no others can do so.  We could define jit-lock as this one
> exception.  (This has the advantage of not involving any change in the
> code, just comments and the Lisp Manual.)
>
> What do people think of that?

I agree with your analysis.  

The "max sit-for" timeout hack may cause more problems than it solves,
so it is not TRT.

In general, timers should never use sit-for, so I think we should document
that in the manual.

But, IMO, if we make it a rule that timers should generally not use
sit-for, then a central function like jit-lock should definitely not
use sit-for!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk