[xfce4-terminal] Large delay in prompt echoing after completion of a command which runs inside a tmux session

[Daniel Fishman]

> I am not able to reproduce the problem on my home 64-bit Arch Linux system either.
> 
> Does a command as simple as say `sleep 5` trigger the problem for you?



You suggestion trying to use 'sleep' provided me with means to find out
some interesting things about the problem.

First of all, the problem does occur with 'sleep', but only when
the sleep is larger than 3.2. In this case the problem always
reproduces. Sleeping for 3 or less does not trigger the problem,
and for values in between (for example, 3.1) it is a toss-up

In addition, using a clock with seconds instead of just a plain stopper
provided a number of fascinating discoveries. First of all, it seems
that every minute, at exactly the same second, there is some kind
of a 'tick' which always causes prompt echoing. In order to better explain
it, let's presume for a convenience that this 'tick' occurs at second 0
(this will usually not be the case, but it is always the same second on the
clock), and let's call a nearest point of time when the clock will shows
second 0 (that is, a nearest second 0 when the tick is supposed to occur) - X.
Also, X-1 is the previous tick, X+1 is the next one etc.
In addition, let's call a point of a time when 'sleep' command is started - S,
the point of time when it actually ends - E, and a point of time when
the prompt is actually echoed - P. Then the following is always true:

If X-1 < S and S < X and E < X, then P <= X.

In other words, if the command is started after previous tick and actually
completes before the next tick, then prompt will be printed at X or before. In
almost all my tests (more than 100 attempts) the prompt was printed *exactly* at
X and not before. I think there were ~4 cases when the prompt was printed
before X (and even in those cases E < P).

Among other things it means that the worst case (when you have to wait the
longest for prompt echoing) occurs when command is started immediately after
the tick.

I don't quite understand why it is so, but maybe terminal's event loop is
triggered every minute and the rest of the time it is busy doing something else
or doing something with 60 seconds timeout (say, waiting for select() to return
and handling events queueued during the wait only after timeouts occurs).
It is definitely not the answer, but a presence of a fixed tick certainly
makes me think along such lines.


Still nothing reproduces on my x64 machine, though.