Processing a stream's output can be queued. If stream_close() is called
before the queue is processed, the RBuffer containing the stream's data
is freed and the next read event would try to access freed memory.
To fix this behavior, use the stream's pending requests counter.
vim-tutor-mode provides a mechanism to write and read interactive
tutorials in vim. It's aim is to replace the venerable vimtutor with a
more modern system.
The plugin's development is maintained at https://github.com/fmoralesc
/vim-tutor-mode
Closes#2351.
The new event processing architecture changed `jobwait()` semantics: Only one
job is processed at time since process_wait only focuses on one queue.
This fixes the problem with a few changes:
- Allow the event queue polled by `process_wait` to be overriden by a new
argument.
- Allow the parent queue to be overriden with `queue_replace_parent`
- Create a temporary queue that serves as the parent for all jobs passed to
`jobwait()`
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.
- Improve the implementation of deferred/immediate events.
- Use the new queue module to change how/when events are queued/processed by
giving a private queue to each emitter.
- Immediate events(which only exist to break uv_run recursion) are now
represented in the `loop->fast_events` queue.
- Events pushed to child queues are propagated to the event loop main queue and
processed as K_EVENT keys.
API functions exposed via msgpack-rpc now fall into two categories:
- async functions, which are executed as soon as the request is parsed
- sync functions, which are invoked in nvim main loop when processing the
`K_EVENT special key
Only a few functions which can be safely executed in any context are marked as
async.
out_data_cb() can return without emptying the full RBuffer (no NL was
seen). Because the shell output stream is stopped until space in the
Rbuffer is freed up, no more shell output is written.
To prevent this, output the full RBuffer when write_output() did not
write anything.
write_output() can also process the same RBuffer content more than once,
if no NL was seen. To prevent NUL bytes from producing new lines (if
lines are not written to a buffer), translate NUL to SOH(1).
Fixes#2983
parse_msgpack() closes a channel's stream on EOF error and the stream's
close callback close_cb() is queued for the next libuv loop iteration.
When parse_msgpack() returns, it has freed the channel and the queued
stream callback will access this freed memory.
To prevent this, increase the channel's reference count and let the
stream's close callback call decref().
Fixes#3128
