summaryrefslogtreecommitdiff
path: root/gio/gsubprocesslauncher-private.h
Commit message (Collapse)AuthorAgeFilesLines
* gio: Add SPDX license headers automaticallyPhilip Withnall2022-05-181-0/+2
| | | | | | | | | | | | | | Add SPDX license (but not copyright) headers to all files which follow a certain pattern in their existing non-machine-readable header comment. This commit was entirely generated using the command: ``` git ls-files gio/*.[ch] | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs' ``` Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Helps: #1415
* gsubprocess: Add G_SUBPROCESS_FLAGS_SEARCH_PATH_FROM_ENVPHristo Venev2021-11-171-1/+0
|
* gsubprocesslauncher: Don’t close target FDs in close() methodPhilip Withnall2021-02-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a regression introduced in commit 67a589e505311. Previously, the source/target FD pairs were stored in `needdup_fd_assignments`, in consecutive entries, so source FDs had even indices and target FDs had odd indices. I didn’t notice that the array index was being incremented by 2 when closing FDs, when porting from the old code. So previously the code was only closing the source FDs; after the port, it was closing source and target FDs. That’s incorrect, as the target FDs are just integers in the parent process. It’s only in the child process where they are actually FDs — and `g_subprocess_launcher_close()` is never called in the child process. This resulted in some strange misbehaviours in any process which used `g_subprocess_launcher_take_fd()` with target FDs which could have possibly aliased with other FDs in the parent process (and which weren’t equal to their mapped source FDs). Thanks to Olivier Fourdan for the detailed bug report. Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Fixes: #2332
* gsubprocess: Use new source/target FD mapping functionality in g_spawn()Philip Withnall2021-02-161-2/+2
| | | | | | | | | | | | | | | | This improves performance by eliminating the use of a `GSpawnChildSetupFunc` in the common case (since that setup code has now moved into `g_spawn*()` itself), and enables the use of the fix to avoid the child error reporting FD being overwritten by target FD mappings, introduced via `g_spawn_async_with_pipes_and_fds()`. It reworks how the source/target FD mapping is stored within `GSubprocessLauncher` to match what `g_spawn*()` uses. The two approaches are equivalent. Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Fixes: #2097
* GSubprocessLauncher: allow to close passed FDsSergio Costas2020-10-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By default, when using g_subprocess_launcher_take_fd() to pass an FD to a child, the GSubprocessLauncher object also takes ownership of the FD in the parent, and closes it during finalize(). This is a reasonable assumption in the majority of the cases, but sometimes it isn't a good idea. An example is when creating a GSubprocessLauncher in JavaScript: here, the destruction process is managed by the Garbage Collector, which means that those sockets will remain opened for some time after all the references to the object has been droped. This means that it could be not possible to detect when the child has closed that same FD, because in order to make that work, both FDs instances (the one in the parent and the one in the children) must be closed. This can be a problem in, as an example, a process that launches a child that communicates with Wayland using an specific socket (like when using the new API MetaWaylandClient). Of course, it isn't a valid solution to manually call close() in the parent process just after the call to spawn(), because the FD number could be reused in the time between it is manually closed, and when the object is destroyed and closes again that FD. If that happens, it will close an incorrect FD. One solution could be to call run_dispose() from Javascript on the GSubprocessLauncher object, to force freeing the resources. Unfortunately, the current code frees them in the finalize() method, not in dispose() (this is fixed in !1670 (merged) ) but it isn't a very elegant solution. This proposal adds a new method, g_subprocess_launcher_close(), that allows to close the FDs passed to the child. To avoid problems, after closing an FD with this method, no more spawns are allowed. Fix: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1677
* gio/: LGPLv2+ -> LGPLv2.1+Sébastien Wilmet2017-05-291-1/+1
| | | | | | | | | | | | | | | | | Sub-directories inside gio/ already processed in a previous commit: - fam/ - gdbus-2.0/ (which contains only codegen/) - gvdb/ - inotify/ - tests/ - win32/ - xdgmime/ Other sub-directories inside gio/: - completion/: no license headers - kqueue/: not LGPL, BSD-style license https://bugzilla.gnome.org/show_bug.cgi?id=776504
* Updated FSF's addressDaniel Mustieles2014-01-311-3/+1
|
* GSubprocess: New class for spawning child processesColin Walters2013-10-171-0/+61
There are a number of nice things this class brings: 0) Has a race-free termination API on all platforms (on UNIX, calls to kill() and waitpid() are coordinated as not to cause problems). 1) Operates in terms of G{Input,Output}Stream, not file descriptors 2) Standard GIO-style async API for wait() with cancellation 3) Makes some simple cases easy, like synchronously spawning a process with an argument list 4) Makes hard cases possible, like asynchronously running a process with stdout/stderr merged, output directly to a file path Much rewriting and code review from Ryan Lortie <desrt@desrt.ca> https://bugzilla.gnome.org/show_bug.cgi?id=672102