[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 <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.
- Re: unwind-protect and inhibit-quit, (continued)
- Re: unwind-protect and inhibit-quit, Stefan Monnier, 2021/07/16
- Re: unwind-protect and inhibit-quit, Thibaut Verron, 2021/07/16
- Re: unwind-protect and inhibit-quit, Stefan Monnier, 2021/07/16
- Re: unwind-protect and inhibit-quit, Felix Dietrich, 2021/07/16
- Re: unwind-protect and inhibit-quit, Stefan Monnier, 2021/07/16
- Re: unwind-protect and inhibit-quit, Felix Dietrich, 2021/07/17
- Re: unwind-protect and inhibit-quit, Eli Zaretskii, 2021/07/17
- Re: unwind-protect and inhibit-quit, Felix Dietrich, 2021/07/17
- Re: unwind-protect and inhibit-quit,
Eli Zaretskii <=