[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: unwind-protect and inhibit-quit

From: Eli Zaretskii
Subject: Re: unwind-protect and inhibit-quit
Date: Sat, 17 Jul 2021 19:34:41 +0300

> From: Felix Dietrich <>
> 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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]