Re: unwind-protect within while-no-input

[Spencer Baugh <sbaugh@janestreet.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Date: Wed, 08 May 2024 15:28:38 -0400
>> 
>> >> How does my-function run the unwind-forms when it is interrupted by
>> >> while-no-input?
>> >
>> > How can a function cause its caller to do anything at all?  It can't.
>> > If the caller wants to make sure some unwind-forms will always run
>> > after my-function either returns locally or exits non-locally, the
>> > caller needs to arrange for that.
>> 
>> I don't want to run the unwind forms "after" my-function returns or
>> exits.  I want them to run wherever they are inside my-function, just
>> like a normal unwind-protect.
>> 
>> Let me try to explain again what I want: I want a completely normal
>> unwind-protect, exactly how unwind-protect works normally:
>> 
>>   (unwind-protect BODYFORM UNWINDFORMS...)
>>   
>>   Do BODYFORM, protecting with UNWINDFORMS.
>>   If BODYFORM completes normally, its value is returned
>>   after executing the UNWINDFORMS.
>>   If BODYFORM exits nonlocally, the UNWINDFORMS are executed anyway.
>> 
>> Except that I want the UNWINDFORMS to not be interrupted by a
>> *surrounding* while-no-input or quit or any other kind of nonlocal exit.
>> 
>> Is there any way to do that?  ("Move the while-no-input inside the
>> unwind-protect" is not an answer, because then it's not a *surrounding*
>> while-no-input anymore)
>
> IMO, you are trying to solve a problem that is impossible to solve in
> general: a function cannot be responsible for the environment in which
> it is called.  You keep talking about while-no-input, but that's just
> an example; there's a virtually infinite number of ways the caller of
> your function can call it in a way that thwarts any attempt of yours
> to prevent non-local exits.  Given enough motivation and effort (and
> reliance on the internal implementation details), you could perhaps
> fix that single case of calling the function inside while-no-input,
> but that will not solve all the rest.
>
> The correct solution to these problems is to document the requirements
> of your function from the callers, and let the callers deal with that
> according to their needs.  (I suspect that in the case that bothers
> you, you yourself are that caller, which makes it easier to implement
> such protocols.)
>
> Btw, you never explained why you are bothered specifically by
> while-no-input.  Nor did you describe the problem.

I'm writing a completion-at-point-function and completion table.  This
table internally uses asynchronous subprocesses to get completions.

This completion-at-point-function and table may be called by the popular
completion frontend corfu-mode.  corfu-mode uses while-no-input around
calls to completion tables.

I want to ensure that my asynchronous subprocesses are deleted even if
my code is interrupted by corfu's while-no-input.

I can't change the protocol of completion tables or
completion-at-point-functions (that's defined by Emacs), and I'm not the
one calling while-no-input (that's corfu-mode).