aboutsummaryrefslogtreecommitdiff
path: root/src/nvim/api/buffer.c
diff options
context:
space:
mode:
authoroni-link <knil.ino@gmail.com>2015-08-07 23:26:01 -0300
committerThiago de Arruda <tpadilha84@gmail.com>2015-08-13 08:52:17 -0300
commit166d8c799f367e64744cef4d9a6ddd386809ece8 (patch)
tree1f13628e137e12648bdd746e28babae31641f196 /src/nvim/api/buffer.c
parent502aee690c980fcb3cfcb3f211dcfad06103db46 (diff)
downloadrneovim-166d8c799f367e64744cef4d9a6ddd386809ece8.tar.gz
rneovim-166d8c799f367e64744cef4d9a6ddd386809ece8.tar.bz2
rneovim-166d8c799f367e64744cef4d9a6ddd386809ece8.zip
process: Remove indeterminism that causes reordering of pty events
Since pty events are queued, it is possible that the reads will be reordered. Example scenario: In the terminal you have output combined from stdout and stderr. A program generates output, first you have some output on stdout, then output on stderr, output on stdout, output on stderr,... The whole output should be interleaved from both streams. Each output generates a read_event and they are placed in the same queue. If the queue is processed, the first read_event will send the whole stdout output to the terminal (on_job_output() consumes the whole buffer). The next read_event is similar for stderr. The remaining read events do nothing because now both RBuffer are already empty. So the terminal would show first the stdout output and after that the stderr output. This commit fixes the problem by disabling stderr stream in pty processes. That's ok because they all represent the same stream(duplicate file descriptors), plus one stream is simpler to deal with.
Diffstat (limited to 'src/nvim/api/buffer.c')
0 files changed, 0 insertions, 0 deletions