[Top][All Lists]
[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
- Single process output reading,
Milan Zamazal <=