Re: process.c: read_process_output: hard coded 4096 bytes read limit

[Thien-Thi Nguyen]

() Miguel Guedes <address@hidden>
() Tue, 25 Jun 2013 08:20:40 +0000 (UTC)

   How would you use accept-process-output with an asynchronous process
   channel?  E.g. when would you call it?  How do you know when there is
   data available?

Presumably the protocol specifies a format for the received data that
includes some kind of "end of message" marker.  You know there is data
available when that marker is not present (given a well-formed message).
For example:

(defun gnugo-synchronous-send/return (message)
  "Return (TIME . STRING) where TIME is that returned by `current-time' and
STRING omits the two trailing newlines.  See also `gnugo-query'."
  (when (gnugo-get :waitingp)
    (error "Sorry, still waiting for %s to play" (gnugo-get :gnugo-color)))
  (gnugo-put :sync-return "")
  (let ((proc (gnugo-get :proc)))
    (set-process-filter
     proc (lambda (proc string)
            (let* ((so-far (gnugo-get :sync-return))
                   (start  (max 0 (- (length so-far) 2))) ; backtrack a little
                   (full   (gnugo-put :sync-return (concat so-far string))))
              (when (string-match "\n\n" full start)
                (gnugo-put :sync-return
                  (cons (current-time) (substring full 0 -2)))))))
    (gnugo-send-line message)
    (let (rv)
      ;; type change => break
      (while (stringp (setq rv (gnugo-get :sync-return)))
        (accept-process-output proc))
      (gnugo-put :sync-return "")
      rv)))

Here, the "end of message" marker is two consecutive newlines, detected
by ‘string-match’.  The (gratuitously dynamically prepared, but somewhat
convenient for copy-and-paste purposes :-D) filter func accumulates the
input and does the final (at EOM) transform, only.  The trigger for the
initial process output is from ‘gnugo-send-line’ after which it is
‘gnugo-synchronous-send/return’ that controls the looping, by monitoring
the accumulated state to detect the transform.

   The only way (that I see) of knowing when there is data available is
   when the filter is first called but can accept-process- output be
   called from within the filter; wouldn't it lead to potentially
   massive recursiveness as the filter is called again and again?

Yes.  That's why the filter func and its (patiently looping) controller
must adhere to some mini protocol defining access to shared state, and
what that state "means".  [Insert VMS mailbox mumblings, here...]

-- 
Thien-Thi Nguyen
GPG key: 4C807502

pgp9cNqFscr5o.pgp
Description: PGP signature