| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Currently there is now way for long running subprocesses like language
servers to gracefully shutdown.
When reacting to the QUIT event and invalidating the process handle
the subprocess will never be killed and destroyed because the
subprocesses are only checked during vis_run.
Collecting and killing subprocesses with invalid handles after the
QUIT event allows graceful shutdown.
|
|
The separation between reading from a subprocess and handling its
life time will be useful for future changes.
|
|
When a new subprocess is created during an EXIT event of
another subprocess new_process_in_pool will update the
process_pool pointer. Since we use a pointer to a pointer
for iterating all processes during vis_process_tick its
value will be different before executing the event and after
creating the new subprocess. This causes the updated pointer
to be erroneously destroyed and leaves the Process of the
reaped child behind which causes consecutive waitpid calls
to fail with ECHILD.
This is fixed by destroying the proper current subprocess
and updating the iteration pointer accordingly.
Fixes: 0b015320382e74fcb385a46a81304f588ed27f77
|
|
|
|
|
|
Rationale
A modern text editor usually includes tools for helping user
to avoid mistakes in texts. Those tools include spell checkers and
programming language integrations. Though vis explicitly states
that the full featured IDE is not a goal, implementing some of
the tools might be achieved using its Lua API. Unfortunatelly
the API misses the ability to start a process and to perform
a communication with it without completely blocking the editor UI,
which is crucial for any tool that performs background tracking of
the inserted text (e. g. language servers).
Implementation details
New feature introduces new API method: communicate. The method
start a new process and returns a handle to communicate with
the process instantly. The patch inserts stderr and stdout
file descriptors of the process to the pselect call of the main loop
used for reading user input to track the process state without
blocking the main loop until the process is finished.
Any changes in the process state cause the iteration of the main loop
and are being exposed to the Lua API as new event: PROCESS_RESPONSE.
|
