bug#13400: 23.4; overlapping process filter calls

[Stefan Monnier]

> complete. If the programmer cannot rely on the documentation to
> be complete here, he or she has no other choice than to assume
> that output can arrive anywhere and he/she _is_ plagued with the
> usual parallel programming problems.

While I largely agree with your points, I'll mention that we *are*
plagued, because lots of functions may (in some cases) end up calling
a blocking operation.  E.g. any call to a file function can block if the
file happens to be handled by Tramp, so any call to a function which
(transitively) calls a file function can itself block.

> It is about a few words making the documentation more precise,
> potentially saving somebody a painful debugging session of
> several hours - similar to what I went through in 2013. Back
> then, I was lucky because clearing the disk caches was enough to
> reproduce the problem. Today with SSD's it is probably much
> harder...

I think preventing recursive filter invocations (by default) would be
much better than warning the programmer about that odd possibility.


        Stefan