From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: process.c: read_process_output: hard coded 4096 bytes read limit Date: Wed, 26 Jun 2013 13:57:39 +0200 Message-ID: <87sj059j9o.fsf@zigzag.favinet> References: <87txkpjhvd.fsf@igel.home> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: ger.gmane.org 1372247729 14612 80.91.229.3 (26 Jun 2013 11:55:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Jun 2013 11:55:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Miguel Guedes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 26 13:55:29 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UroJs-0000YT-Dg for ged-emacs-devel@m.gmane.org; Wed, 26 Jun 2013 13:55:28 +0200 Original-Received: from localhost ([::1]:34928 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UroJs-0003eZ-4x for ged-emacs-devel@m.gmane.org; Wed, 26 Jun 2013 07:55:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UroJo-0003eE-1W for emacs-devel@gnu.org; Wed, 26 Jun 2013 07:55:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UroJm-0006F6-7G for emacs-devel@gnu.org; Wed, 26 Jun 2013 07:55:23 -0400 Original-Received: from smtp207.alice.it ([82.57.200.103]:38600) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UroJl-0006Eo-TL for emacs-devel@gnu.org; Wed, 26 Jun 2013 07:55:22 -0400 Original-Received: from zigzag.favinet (79.1.74.199) by smtp207.alice.it (8.6.060.15) id 51B4DE8A0353E403; Wed, 26 Jun 2013 13:55:20 +0200 Original-Received: from ttn by zigzag.favinet with local (Exim 4.72) (envelope-from ) id 1UroMC-0003pC-Oy; Wed, 26 Jun 2013 13:57:52 +0200 In-Reply-To: (Miguel Guedes's message of "Tue, 25 Jun 2013 08:20:40 +0000 (UTC)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.57.200.103 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:161084 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable () Miguel Guedes () 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 lit= tle (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 =3D> 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 =E2=80=98string-match=E2=80=99. 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 =E2=80=98gnugo-send-line=E2=80=99 after whic= h it is =E2=80=98gnugo-synchronous-send/return=E2=80=99 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...] =2D-=20 Thien-Thi Nguyen GPG key: 4C807502 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlHK1zkACgkQZwMiJEyAdQLhTwCg5MwLYS7JL6/ndQpowlTfkVru KSMAoIMj37A0Ie14lgun5+ow604WhR/+ =ZWE0 -----END PGP SIGNATURE----- --=-=-=--