Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Matthias Dahl]

Hello Eli...

On 28/10/17 11:28, Eli Zaretskii wrote:

> It lacks the Lisp backtrace ("xbacktrace" can produce it), and the
> fact that most arguments are either optimized out or complex data
> types shown as "..." makes the backtrace much less useful.

Sorry, like I said, I was in a hurry that was all I could provide at
that time. Attached you will find a full backtrace from a proper debug
build w/o optimization -- I usually only run those when really debugging
something, otherwise I keep debug symbols around for an optimized build,
that will at least give me a starting point and an idea when something
goes wrong.

> But if the wrong call to accept-process-output have read the process
> output, it could have also processed it and delivered the results to
> the wrong application, no?

Given that fact that a filter is registered for a given process, and
thus it is this filter that gets called whenever process output is ready
and needs to be processed, a timer or filter would have to replace that
filter with its own through set-process-filter for this to happen. And
that is something I would clearly consider a bug, since no filter or
timer should do something like that.

Naturally there is also the weird case when accept-process-output was
called from a hook by some package which expects that data and needs it
but doesn't consider that a timer could get called during that time and
the package itself has a timer setup that will also interact with that
very same process, trying to read data back from some interaction with
it. That will naturally fail as well... either way, with or without my
patch. And again, I would consider this a bug.

If a package interacts with its own processes, it should be careful and
consider that timers/filters get called while accept-process-output is
called and take that into account.

> I think we need a thorough and detailed understanding of what's going
> on in this case, before we can discuss the solutions, yes.  IME,
> trying to fix a problem without a good understanding what it is that
> we are fixing tends to produce partial solutions at best, and new bugs
> at worst.

I fully agree with your opinion, I just thought I already properly
explained in my lenghty mails what was going on behind the scenes and
how my (rather simple) solution fixes it.

> So please reproduce this in an unoptimized build, and please also show
> the Lisp backtrace in this scenario.  Then let's take it from there.

Like said earlier, you will find that attached. But keep in mind, that
will not be as helpful as you might hope since you will only see where
the hangs occurs (I already stated that) but not why. At that point, the
timers have already run.

> I do.  I believe we must understand this situation very well before we
> reason about its solution.

One example is semantic. Its idle timers use semantic-throw-on-input
which calls accept-process-output without any arguments. Just as an
example.

So long,
Matthias

-- 
Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu

emacs-bt-full.txt
Description: Text document