From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Milan Zamazal Newsgroups: gmane.emacs.devel Subject: Single process output reading Date: Mon, 16 Aug 2004 11:21:36 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <874qn35tgf.fsf@zamazal.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1092648673 5297 80.91.224.253 (16 Aug 2004 09:31:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 16 Aug 2004 09:31:13 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 16 11:31:04 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BwdpX-0007QG-00 for ; Mon, 16 Aug 2004 11:31:04 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Bwdtd-0007LN-TU for ged-emacs-devel@m.gmane.org; Mon, 16 Aug 2004 05:35:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BwdtR-0007L8-BF for emacs-devel@gnu.org; Mon, 16 Aug 2004 05:35:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BwdtP-0007Kq-8d for emacs-devel@gnu.org; Mon, 16 Aug 2004 05:35:04 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BwdtP-0007Kg-01 for emacs-devel@gnu.org; Mon, 16 Aug 2004 05:35:03 -0400 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BwdpH-0001FU-Kh for emacs-devel@gnu.org; Mon, 16 Aug 2004 05:30:48 -0400 Original-Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BwdpF-0001NC-00 for ; Mon, 16 Aug 2004 11:30:45 +0200 Original-Received: from r2ao37.chello.upc.cz ([62.245.104.37]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Aug 2004 11:30:45 +0200 Original-Received: from pdm by r2ao37.chello.upc.cz with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Aug 2004 11:30:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 57 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: r2ao37.chello.upc.cz X-Face: >kl&pL}(a*u\BCj7Q, \Yoq35~, 4dAu"CPGaJ[ahMli9uu#aF7dWxc3L.eaK2RWRU|', E+. -':&gJ-JAZ/N$f^4-3?G7M&Knna[A=lJ$}^!%@vuvulVl6-)x.V8RZ7fW9< User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:4f9syQVCe3t7I+iEtMk4it7Uglo= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 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 Xref: main.gmane.org gmane.emacs.devel:26272 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:26272 I think a way to read an output of just a single asynchronous process in Emacs is needed. I.e. a way to invoke accept-process-output without possible invocation of another process filter function or a timer. Why is it needed? Currently, there's no way to do it AFAIK, which basically means that all process filter functions must be reentrant. Making a process filter function reentrant is not always a trivial task and it's useless to do so except that the scenario like the following one can happen: A process filter function `foo' is invoked. It reports about the process reading progress via the `message' function. `message' can be advised, e.g. by some speech output function. The speech output function communicates with a speech synthesizer through a network process and it calls accept-process-output to read the synthesizer's answer. But within the accept-process-output, `foo' can be invoked again. If it is not reentrant, errors can happen. This is what actually happens in the speechd-el speech output system which, among others, advises the `message' function. So any filter function calling `message' (or doing some other actions handled by the speech output system) is fragile to this problem. There's a workaround for this: To write an external program resending the data/answer to/from the desired network connection and to call this program synchronously from Emacs (anytime a piece of data is to be sent to the network connection) with call-process. This is what I actually did, but I don't think it's a good way of solving the problem, both from the point of view of the programmer and the user. IMO a better way would be to allow restricting accept-process-output to just a single process output reading. Then the speech output system, aware of possible consequences of advising 'message' etc., could invoke accept-process-output in the restricted form, without the danger of unwanted side effects. I need this feature, so I'm willing to implement it unless someone more competent would like to do it. My questions are: - Do you agree with my analysis or do you have a better suggestion how to solve the presented problem? - Do you have some suggestions how the restricted invocation of accept-process-output might look? New optional argument? - Do you have some implementation advice? Thanks for any help. Regards, Milan Zamazal -- http://www.zamazal.org