If GUI is force-closed, the Neovim process continues to run

[oakes]

We need a way to make the Neovim process shut itself down if the GUI doesn't shut down cleanly.

[GuillaumeGomez]

If the Neovim process is a child of the GUI process, shoud it stop by itself when its parent dies ?

[oakes]

It is indeed a child process, but it isn't killed automatically. See this discussion, which seems to suggest that there is no cross-platform way to ensure a child process is killed when its parent exits.

[tarruda]

If you communicate with Neovim using stdio(--embed cli flag), Neovim will exit when the parent dies.

For other types of connection, this could be fixed if Neovim had a ChannelClosed autocmd: au ChannelClosed [ui_channel_id] wqa!.

[oakes]

The reason I'm not using --embed is because VteTerminal uses stdin/stdout to display it. Perhaps that could change if I began using a DrawingArea widget like python-client. I recall you were writing a version of that in C, correct?

[tarruda]

I recall you were writing a version of that in C, correct?

I had plans to do it, but didn't start anything yet.

[oakes]

@tarruda I'm considering trying to implement ui.h directly so I don't need to run neovim in a separate process. I figure it should be possible if I use a DrawingArea the same way you did, and run Neovim in a separate thread. Do you have any advice on how to do this? Should I somehow directly replace the ui.c functions with my own? Rust is able to export functions so they can be used from C, but this type of monkey-patching is new to me.

[tarruda]

@oakes I'm currently refactoring the event/UI subsystems to allow this(neovim/neovim#2371). The terminal UI is called directly because it runs in the same thread, but soon I will make some changes that will require the UI functions to run in a separate thread like a GUI toolkit, so it will be much simpler to do what you want.

[oakes]

Great, I was wondering if my idea might have threading problems so I'll follow that issue. I have temporarily stopped rebasing my fork on the latest Neovim commits, however, because I noticed api_free_array started crashing. I believe I tracked it down to this commit, but haven't found the time to investigate further yet -- it could be something I'm doing wrong in neovim-rs. Anyway, once I solve that, I'll be ready to get those incoming changes.

[tarruda]

Great, I was wondering if my idea might have threading problems so I'll follow that issue. I have temporarily stopped rebasing my fork on the latest Neovim commits, however, because I noticed api_free_array started crashing. I believe I tracked it down to this commit, but haven't found the time to investigate further yet -- it could be something I'm doing wrong in neovim-rs. Anyway, once I solve that, I'll be ready to get those incoming changes.

We must allow library users to pass pointers to malloc, realloc, calloc and free implementations so it's possible to pass memory from/to neovim(which now uses jemalloc by default, but without redefining the standard allocator symbols)

[oakes]

I am indeed using malloc in one place, so I take it that all I need to do is use je_malloc instead? Either that, or disable jemalloc, I suppose.

[tarruda]

Yes, but ideally we'd have a function that allows the library user to override the allocation functions used by nvim