GNU bug report logs - #13400
23.4; overlapping process filter calls

Previous Next

Full log

Message #8 received at 13400 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Hendrik Tews <hendrik <at> askra.de>
Cc: 13400 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#13400: 23.4; overlapping process filter calls
Date: Fri, 26 Jul 2019 23:38:46 -0400

[Message part 1 (text/plain, inline)]

Hendrik Tews <hendrik <at> askra.de> writes:

> because Stefan Monnier asked for it
> (http://lists.inf.ed.ac.uk/pipermail/proofgeneral-devel/2013/000296.html)

[Note: meanwhile the section number has changed to 38 instead of 37.]

> - Section "37.9 Receiving Output from Processes" does not list
>   process-send-string. How about other blocking I/O functions?

In the attached patch, I've added a mention/xref for functions which send
data to processes.

> - Same in "37.9.2. Process Filter Functions"

This section is repeated twice (I addressed the second instance below).

> - Same in "37.4 Creating an Asynchronous Process" ,
>   process-send-string is neither waiting for input not time
>   delay.

I don't see any mention of process-send-string in that section, nor how
it's relevant to the rest of this report.

> - "37.7 Sending Input to Processes" says that filters can run
>   inside process-send-string, but it could be clearer about the
>   point that this can also happen inside the same filter for the
>   same process.

I'm not really convinced that is necessary.

> - "37.9.2 Process Filter Functions" ignores the problem
>   completely. There should be a paragraph clearly stating this
>   problem. Further, it would be nice, if the filter function
>   example could be extended to correctly deal with this problem.

I added a mention of the possibility of recursion.  I'm not sure about
making an example (specifically, what is the best way to deal with this
problem?).

[0001-Note-that-process-filter-can-be-called-recursively-B.patch (text/plain, attachment)]

[Message part 3 (text/plain, inline)]

> To make it easier in the future to deal with this problem, I
> suggest to add a process specific flag
> ``process-no-concurrent-filters''. When this flag is t for a
> process, Emacs accepts output from this process inside a filter
> but buffers it without calling the filter. The call to the filter
> is delayed until a point where no filter for this process is
> running. An error is signaled, if the buffered output exceeds a
> certain size.

I thought of just making a wrapper in Lisp instead, this saves the need
to complicate the process C code with yet another flag; it's already
tricky enough as it is.

;;; -*- lexical-binding: t -*-

(defun make-buffered-filter (filter)
  (let ((filtering nil)
        (buffered nil)
        (process nil))
    (lambda (proc str)
      (if process
          (unless (eq process proc)
            (error "Buffered filter used in different processes: %S, %S"
                   proc process))
        (setq process proc))
      (push str buffered)
      (unless filtering
        (setq filtering t)
        (unwind-protect
            (while buffered
              (setq str (apply #'concat (nreverse buffered)))
              (setq buffered nil)
              (funcall filter proc str))
          (setq filtering nil))))))

;; Can be used like
(set-process-filter my-process (make-buffered-filter #'my-filter-function))

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.