GNU bug report logs -
#70221
[PATCH] New function `funcall-later`
Previous Next
Full log
Message #47 received at 70221 <at> debbugs.gnu.org (full text, mbox):
> 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 1 year and 81 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.