[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13400: 23.4; overlapping process filter calls
From: |
Noam Postavsky |
Subject: |
bug#13400: 23.4; overlapping process filter calls |
Date: |
Fri, 26 Jul 2019 23:38:46 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2.90 (gnu/linux) |
Hendrik Tews <hendrik@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
Description: patch
> 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))
- bug#13400: 23.4; overlapping process filter calls,
Noam Postavsky <=