Re: unwind-protect and inhibit-quit

[Eli Zaretskii]

> From: Felix Dietrich <felix.dietrich@sperrhaken.name>
> Date: Sat, 17 Jul 2021 17:46:52 +0200
> 
> > What problem(s) this is intended to fix/handle?
> 
> Still the problem of process littering and, more generally, ensuring
> that certain clean up operations are run and values needed for those
> clean up operations are not lost in limbo.  I admit that this problem,
> that quit is signalled so timed that the return value of a function is
> lost in that ethereal space between return and assignment, is an so
> unlikely one that one may ignore it in practice—but it piqued my
> interest.

The manual tells you there's no easy fix for that.

>     (defun ftp-setup-buffer ()
>       (let (process)
>         (condition-case err
>             (progn
>               (setq process (start-process …))
>                process ; RETURN
>               )
>           (quit
>            (and (processp process)
>                 (kill-process process))
>            (signal (car err) (cdr err))))))
> 
> 
> If you can 1. trust that ‘start-process’ will either return a process
> object or, in case of a quit, clean-up whatever intermediary process it
> may have created before it propagates the quit

This is guaranteed, AFAICT.

> and 2.1. that a quit
> received while a RETURN is in process is either signalled inside the
> called ‘ftp-setup-buffer’ at a point where in can still be handled by
> the ‘condition-case’ or 2.2. only once the returned value has either
> been assigned or became irrelevant in the caller because the next form
> is being evaluated, then canʼt killing of the process be guaranteed?

I lost you here, because this whole code is the code of
ftp-setup-buffer.  So we can only discuss what happens inside that
function.

Basically, the quit will be processed inside setq, and if the user
indeed pressed C-g, the assignment will not happen, and the value of
the variable 'process' will not be a process object.  That is the
problem for which "there's no easy way of fixing it", AFAIU.

> Alas, it is probably not as “simple” as I imagine: what have I missed?
> What do I not know?

I suggest to read the code which implements make-process to see the
details, and then the implementation of setq.  And one more thing: the
time when the user presses C-g and the time when Emacs will react to
it could be far apart.  Pressing C-g basically just sets a flag.