GNU bug report logs -
#70221
[PATCH] New function `funcall-later`
Previous Next
Full log
View this message in rfc822 format
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 70221 <at> debbugs.gnu.org
> Date: Sat, 06 Apr 2024 16:00:53 -0400
>
> >> `condition-case-unless-debug` is very different from `safe_calln`.
> >> It doesn't prevent non-local exits nor prevent showing a debugger.
> > It catches errors, doesn't it?
>
> What's good about it?
>
> > That's what bothers me with CALLN.
>
> With CALLN the errors don't get caught by `safe_calln` so they get
> caught further up the stack, which seems fine by me.
> What problem/scenario are you thinking about?
That we throw to top-level from a normal processing loop. Why should
we not prevent that if we can? Why are you so objected to doing what
we have always done there?
> >> >> I can't see any good reason why we'd need to protect the
> >> >> C code from non-local exits in `timer_check_2`.
> >> > Because it will prevent timers from being called?
> >>
> >> Why would it? after the non-exit is caught somewhere up the stack, we'd
> >> eventually come back to `timer_check_2` and run the timer then.
> >
> > Unless the same buggy funcall-later is again in the list, right?
>
> No: we bump it off the list before the CALLN, specifically to
> avoid this problem. They don't auto-repeat like some timers.
The Lisp program that initiated it could initiate another one soon
enough. Why risk that when the solution is so easy? I really don't
understand your objections here. Is there any harm that can possibly
be done by catching errors, like timers do? If not, why not do it?
> >> > From my POV, any code that runs from some background facility must
> >> > inhibit QUIT, because the user can type C-g at any moment.
> >> Agreed, and `funcall-later` doesn't run it "in the background", it runs
> >> it at the end of the current code.
> > How is this different from running timers?
>
> Non-0s timers are run in the context of some future command (or in the
> middle of "idle" time). `funcall-later` are run before we get to idle
> time or to the next user input
The funcall-later functions are run in exactly the same context. Look
at the code: they are called inside the same loop in timer_check_2.
So the context is exactly the same.
> so if the user hits C-g during them, it's no different from hitting
> C-g during the main part of the command. It's realy more like
> `post-command-hook` (incidentally, I've been thinking that maybe we
> should call `internal--run-pending-funcalls` when we run
> `post-command-hook`).
Whatever happens with zero timers happens also with funcall-later
functions. So the same considerations apply. From the user POV,
Emacs is idle, so the user can press C-g at any moment. E.g., it is
customary to press C-g when Emacs sits at the prompt in the
minibuffer: both timers and funcall-later functions can be run at that
time.
> >> - It determines which part of the time-behavior we should consider as
> >> something we want to document and guarantee, as opposed to the part
> >> which is incidental and which we may prefer to document as not to be
> >> relied on.
> > I'm not sure I understand where you are going with this. It seems
> > very easy to tell when the delayed functions will be called, so why
> > are we arguing?
>
> I'm not sure the current implementation provides the behavior we want.
> So I think it's worthwhile thinking about what it is that we want.
> E.g. another implementation could be to have a separate thread running
> those functions. Or as mentioned above we could run them from
> `post-command-hook`. ...
As long as the code is on the branch, I don't really care. But the
moment it lands on master, it should have the proper documentation,
and if by that time the implementation doesn't change, I insist on
saying something about when these functions are called, because I
think it's important. If the implementation does change, I will, of
course, revisit my opinion (hopefully, during the review of the
modified code that is to follow).
This bug report was last modified 351 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.