emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Single process output reading


From: Milan Zamazal
Subject: Single process output reading
Date: Mon, 16 Aug 2004 11:21:36 +0200
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (gnu/linux)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]