Re: unwind-protect and inhibit-quit

[Felix Dietrich <felix.dietrich@sperrhaken.name>]

Stefan Monnier via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

>> Now I'm curious too... Would something like this work?
>>
>>  (let ((inhibit-quit t))
>>    (setq process
>>       (let ((inhibit-quit nil))
>>          (ftp-setup-buffer host file))))
>
> No.  The problem is not in the `setq` itself but in the fact that
> a non-local exit from `ftp-setup-buffer` (e.g. because of `C-g`) will
> cause `ftp-setup-buffer` not to return the process.

But at which point is the ‘quit-flag’ actually handled?  When unwinding
the function, just before returning a value?  The macro
‘with-local-quit’ states that the “quit-flag” “will not be handled until
the next function call”[1].  Could, therefore, a careful and cooperative
“ftp-setup-buffer” ensure that the process is either cleaned-up or
returned?  I am thinking of something like the following:


    (defun ftp-setup-buffer (host file)
      (let (process)
        (condition-case nil
            (progn
              (let ((inhibit-quit t))
                ;; I am assuming that ‘start-process’ does not block for a
                ;; long time.  Does it?  Maybe with a defective drive?
                ;; How about ‘start-file-process’?
                (setq process (start-process …)))
              ;; do more stuff
              process)
          (quit
           ;; I guess another quit could happen here; nest more
           ;; ‘condition-case’?  Itʼs ‘condition-case’ all the way down.
           (and (processp process)
                (kill-process process))
           (setq quit-flag t)
           ;; Propagate quit and make sure an outside handler receives it.
           ;; I do not have a good understanding of this.  I simply copied
           ;; it from the ‘with-local-quit’ macro.
           (eval '(ignore nil))))))


    (let (process)
      (unwind-protect
          (let ((inhibit-quit t))
            (setq process
                  (with-local-quit
                    (ftp-setup-buffer host file)))
            ;; do stuff
            )
        (and (processp process) (kill-process process))))


> We should devise a more reliable API, tho I'm not completely sure what
> it should look like.  Maybe
>
>     (let ((list-of-created-processes nil))
>       (unwind-protect ...
>         (mapc #'delete-process list-of-created-processes)))
>
> Where the low-level primitives which create processes add them to
> `list-of-created-processes`.

How do the low-level C functions to create processes handle quit?  If it
happens inside of them, they should be responsible for killing the
process.  But I am understanding that there is a step in between the
creation of the process object, the return from a process creation
primitive, and the assignment of the process object to a variable.

> But then this gets into trouble when some unrelated code is run during
> `...` (e.g. via timers or whatnot) which creates unrelated processes,
> so we'd need some extra care to make sure those processes don't get
> added to "the same" `list-of-created-processes`.

If I am allowed to spitball here: create another function call to
“claim” a process, and subject unclaimed processes to a similar clean-up
routine as buffers (with ‘clean-buffer-list’):


    (let (process)
      (unwind-protect
          (progn
            (setq process (ftp-setup-buffer host file))
            (claim-process process)
            ;; do stuff
            )
        (and (processp process)
             (kill-process process))))


Add an optional CLAIMED parameter to process creation primitives that
defaults to t in order to not disturb existing code.  Naturally, I have
no idea how to implement that nor the skill to figure this out.


Footnotes:
[1]  Although there is also this information in (info "(elisp)
     Quitting"):

     “Eventually, ‘inhibit-quit’ will become ‘nil’ again, such as when
     its binding is unwound at the end of a ‘let’ form.  At that time,
     if ‘quit-flag’ is still non-‘nil’, the requested quit happens
     immediately.”

-- 
Felix Dietrich