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>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70221 <at> debbugs.gnu.org
Subject: bug#70221: [PATCH] New function `funcall-later`
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?

>> >> 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.

>> > 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, 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`).

>> - 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`. ...


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.