aboutsummaryrefslogtreecommitdiff
path: root/src/nvim/os/process.c
Commit message (Collapse)AuthorAge
* refactor: rename "process" => "proc" #30387Justin M. Keyes2024-09-15
| | | | | | | | | | | | Problem: - "process" is often used as a verb (`multiqueue_process_events`), which is ambiguous for cases where it's used as a topic. - The documented naming convention for processes is "proc". - `:help dev-name-common` - Shorter is better, when it doesn't harm readability or discoverability. Solution: Rename "process" => "proc" in all C symbols and module names.
* refactor(api): use arena for channel info and terminal infobfredl2024-02-18
|
* build: don't define FUNC_ATTR_* as empty in headers (#26317)zeertzjq2023-11-30
| | | | | | FUNC_ATTR_* should only be used in .c files with generated headers. Defining FUNC_ATTR_* as empty in headers causes misuses of them to be silently ignored. Instead don't define them by default, and only define them as empty after a .c file has included its generated header.
* refactor: fix headers with IWYUdundargoc2023-11-28
|
* build: enable IWYU on macdundargoc2023-11-27
|
* build: remove PVSdundargoc2023-11-12
| | | | | | | We already have an extensive suite of static analysis tools we use, which causes a fair bit of redundancy as we get duplicate warnings. PVS is also prone to give false warnings which creates a lot of work to identify and disable.
* refactor: adjust headers according to the style guide (#23934)dundargoc2023-06-06
| | | System headers should be included first to prevent naming conflicts.
* refactor(api): new helper macrosFamiu Haque2023-05-23
| | | | Adds new API helper macros `CSTR_AS_OBJ()`, `STATIC_CSTR_AS_OBJ()`, and `STATIC_CSTR_TO_OBJ()`, which cleans up a lot of the current code. These macros will also be used extensively in the upcoming option refactor PRs because then API Objects will be used to get/set options. This PR also modifies pre-existing code to use old API helper macros like `CSTR_TO_OBJ()` to make them cleaner.
* refactor: uncrustifydundargoc2023-04-26
| | | | Notable changes: replace all infinite loops to `while(true)` and remove `int` from `unsigned int`.
* vim-patch:8.2.3041: detecting if the process of a swap file is running failszeertzjq2022-11-17
| | | | | | | | | | Problem: Detecting if the process of a swap file is running fails if the process is owned by another user. Solution: Check for the ESRCH error. (closes vim/vim#8436) https://github.com/vim/vim/commit/44dea9da4b2a21dd1e03f2bd94b4f2679d4613e5 Co-authored-by: Bram Moolenaar <Bram@vim.org>
* build: allow IWYU to fix includes for all .c filesdundargoc2022-11-15
| | | | | | | | | | Allow Include What You Use to remove unnecessary includes and only include what is necessary. This helps with reducing compilation times and makes it easier to visualise which dependencies are actually required. Work on https://github.com/neovim/neovim/issues/549, but doesn't close it since this only works fully for .c files and not headers.
* vim-patch:8.1.0941: macros for MS-Windows are inconsistent (#20215)dundargoc2022-09-18
| | | | | | | Problem: Macros for MS-Windows are inconsistent, using "32", "3264 and others. Solution: Use MSWIN for all MS-Windows builds. Use FEAT_GUI_MSWIN for the GUI build. (Hirohito Higashi, closes vim/vim#3932) https://github.com/vim/vim/commit/4f97475d326c2773a78561fb874e4f23c25cbcd9
* refactor: format files with uncrustify #15663dundargoc2021-09-14
|
* vim-patch:8.1.0572: stopping a job does not work properly on OpenBSDDaniel Hahler2019-07-30
| | | | | | | | | | | | Problem: Stopping a job does not work properly on OpenBSD. Solution: Do not use getpgid() to check the process group of the job processs ID, always pass the negative process ID to kill(). (George Koehler, closes vim/vim#3656) https://github.com/vim/vim/commit/76ab4fd61901090e6af3451ca6c5ca0fc370571f Ref: https://github.com/neovim/neovim/issues/9704 Ref: https://github.com/neovim/neovim/issues/10182#issuecomment-514450069 Closes https://github.com/neovim/neovim/pull/10660
* vim-patch:8.1.1231: asking about existing swap file unnecessarilyJustin M. Keyes2019-04-29
| | | | | | | | | | | | Problem: Asking about existing swap file unnecessarily. Solution: When it is safe, delete the swap file. Remove HAS_SWAP_EXISTS_ACTION, it is always defined. (closes vim/vim#1237) https://github.com/vim/vim/commit/67cf86bfff5fd5224d557d81cb146f46e33b831c N/A: vim-patch:8.1.1232 vim-patch:8.1.1233 vim-patch:8.1.1236
* build/OpenBSD: need -lpthread -lc++abi for LuaJIT (#8215)Utkarsh Anand2018-04-02
|
* lintJames McCoy2018-03-29
|
* build/NetBSD: use kinfo_proc2; undef uint64_t (#8197)Utkarsh Anand2018-03-29
| | | | | | | | | | closes #8196 For historical reasons, uint64_t and friends are defined both as typedefs and macros. Some platforms that do that define the macros as identity (#define uint64_t uint64_t), others like NetBSD define to the backing type (#define uint64_t __uint64_t). This is normally transparent, except when multiple levels of macro expansions are used inconsistently.
* API: nvim_get_proc()Justin M. Keyes2018-03-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TODO: "exepath" field (win32: QueryFullProcessImageName()) On unix-likes `ps` is used because the platform-specific APIs are a nightmare. For reference, below is a (incomplete) attempt: diff --git a/src/nvim/os/process.c b/src/nvim/os/process.c index 09769925aca5..99afbbf290c1 100644 --- a/src/nvim/os/process.c +++ b/src/nvim/os/process.c @@ -208,3 +210,60 @@ int os_proc_children(int ppid, int **proc_list, size_t *proc_count) return 0; } +/// Gets various properties of the process identified by `pid`. +/// +/// @param pid Process to inspect. +/// @return Map of process properties, empty on error. +Dictionary os_proc_info(int pid) +{ + Dictionary pinfo = ARRAY_DICT_INIT; +#ifdef WIN32 + +#elif defined(__APPLE__) + char buf[PROC_PIDPATHINFO_MAXSIZE]; + if (proc_pidpath(pid, buf, sizeof(buf))) { + name = getName(buf); + PUT(pinfo, "exepath", STRING_OBJ(cstr_to_string(buf))); + return name; + } else { + ILOG("proc_pidpath() failed for pid: %d", pid); + } +#elif defined(BSD) +# if defined(__FreeBSD__) +# define KP_COMM(o) o.ki_comm +# else +# define KP_COMM(o) o.p_comm +# endif + struct kinfo_proc *proc = kinfo_getproc(pid); + if (proc) { + PUT(pinfo, "name", cstr_to_string(KP_COMM(proc))); + xfree(proc); + } else { + ILOG("kinfo_getproc() failed for pid: %d", pid); + } + +#elif defined(__linux__) + char fname[256] = { 0 }; + char buf[MAXPATHL]; + snprintf(fname, sizeof(fname), "/proc/%d/comm", pid); + FILE *fp = fopen(fname, "r"); + // FileDescriptor *f = file_open_new(&error, fname, kFileReadOnly, 0); + // ptrdiff_t file_read(FileDescriptor *const fp, char *const ret_buf, + // const size_t size) + if (fp == NULL) { + ILOG("fopen() of /proc/%d/comm failed", pid); + } else { + size_t n = fread(buf, sizeof(char), sizeof(buf) - 1, fp); + if (n == 0) { + WLOG("fread() of /proc/%d/comm failed", pid); + } else { + size_t end = MIN(sizeof(buf) - 1, n); + end = (end > 0 && buf[end - 1] == '\n') ? end - 1 : end; + buf[end] = '\0'; + PUT(pinfo, "name", STRING_OBJ(cstr_to_string(buf))); + } + } + fclose(fp); +#endif + return pinfo; +}
* win: nvim_get_proc_children()Justin M. Keyes2018-03-16
| | | | | | | | | | | | TODO: Raymond Chen explains[1] racy behavior of the CreateToolhelp32Snapshot approach. Better approach: > create a job object and put process P in it. Then call > QueryInformationJobObject with JobObjectBasicProcessIdList to get the > list of child processes. [1] "Why is CreateToolhelp32Snapshot returning incorrect parent process IDs all of a sudden?" https://blogs.msdn.microsoft.com/oldnewthing/20150403-00/?p=44313
* nvim_get_proc_children: fallback to shellJustin M. Keyes2018-03-16
| | | | | /proc/…/children may be unavailable because of an unset kernel option. Fallback to `pgrep` invoked in a shell.
* API: nvim_get_proc_children()Justin M. Keyes2018-03-16
| | | | ref https://github.com/libuv/libuv/pull/836
* win: os_proc_tree_kill()Justin M. Keyes2018-03-16
XXX: comment at https://stackoverflow.com/q/1173342 : > Windows recycles PIDs quite fast, you have to be extra careful not > to kill unrelated processes. These APIs will report PPIDs for long > dead processes whose PIDs may have been recycled. Check the parent > start date to make sure it is related to the processes you spawned.