From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!not-for-mail
From: Miguel Guedes <miguel.a.guedes@gmail.com>
Newsgroups: gmane.emacs.devel
Subject: Re: process.c: read_process_output: hard coded 4096 bytes read limit
Date: Tue, 25 Jun 2013 08:20:40 +0000 (UTC)
Message-ID: <kqbjso$6fk$1@ger.gmane.org>
References: <kq3ssm$b00$1@ger.gmane.org> <87txkpjhvd.fsf@igel.home>
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: ger.gmane.org 1372148474 5138 80.91.229.3 (25 Jun 2013 08:21:14 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Tue, 25 Jun 2013 08:21:14 +0000 (UTC)
To: emacs-devel@gnu.org
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 25 10:21:14 2013
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
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 <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1UrOUy-0000L0-Rf
	for ged-emacs-devel@m.gmane.org; Tue, 25 Jun 2013 10:21:12 +0200
Original-Received: from localhost ([::1]:39735 helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1UrOUy-0005PG-6u
	for ged-emacs-devel@m.gmane.org; Tue, 25 Jun 2013 04:21:12 -0400
Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41134)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ged-emacs-devel@m.gmane.org>) id 1UrOUr-0005P3-Ou
	for emacs-devel@gnu.org; Tue, 25 Jun 2013 04:21:10 -0400
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ged-emacs-devel@m.gmane.org>) id 1UrOUm-0004gg-Oi
	for emacs-devel@gnu.org; Tue, 25 Jun 2013 04:21:05 -0400
Original-Received: from plane.gmane.org ([80.91.229.3]:38825)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ged-emacs-devel@m.gmane.org>) id 1UrOUm-0004gW-Ha
	for emacs-devel@gnu.org; Tue, 25 Jun 2013 04:21:00 -0400
Original-Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <ged-emacs-devel@m.gmane.org>) id 1UrOUk-00009r-9P
	for emacs-devel@gnu.org; Tue, 25 Jun 2013 10:20:58 +0200
Original-Received: from 176.24.186.11 ([176.24.186.11])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <emacs-devel@gnu.org>; Tue, 25 Jun 2013 10:20:58 +0200
Original-Received: from miguel.a.guedes by 176.24.186.11 with local (Gmexim 0.1
	(Debian)) id 1AlnuQ-0007hv-00
	for <emacs-devel@gnu.org>; Tue, 25 Jun 2013 10:20:58 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-Lines: 13
Original-X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: 176.24.186.11
User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2)
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
	recognized.
X-Received-From: 80.91.229.3
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=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:161014
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/161014>

On Sun, 23 Jun 2013 11:28:38 +0200, Andreas Schwab wrote:

> If you call accept-process-output with this process it should read
> whatever is available without delay.

Thanks, Andreas.

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?  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?