glib/gio/gsubprocesslauncher-private.h

61 lines
1.5 KiB
C
Raw Normal View History

/* GIO - GLib Input, Output and Streaming Library
*
* Copyright (C) 2012 Colin Walters <walters@verbum.org>
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General
2014-01-23 12:58:29 +01:00
* Public License along with this library; if not, see <http://www.gnu.org/licenses/>.
*/
#ifndef __G_SUBPROCESS_CONTEXT_PRIVATE_H__
#define __G_SUBPROCESS_CONTEXT_PRIVATE_H__
#include "gsubprocesslauncher.h"
G_BEGIN_DECLS
struct _GSubprocessLauncher
{
GObject parent;
GSubprocessFlags flags;
gboolean path_from_envp;
char **envp;
char *cwd;
#ifdef G_OS_UNIX
gint stdin_fd;
gchar *stdin_path;
gint stdout_fd;
gchar *stdout_path;
gint stderr_fd;
gchar *stderr_path;
GArray *basic_fd_assignments;
GArray *needdup_fd_assignments;
GSubprocessLauncher: allow to close passed FDs 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
2020-10-04 14:34:41 +02:00
gboolean closed_fd;
GSpawnChildSetupFunc child_setup_func;
gpointer child_setup_user_data;
GDestroyNotify child_setup_destroy_notify;
#endif
};
void g_subprocess_set_launcher (GSubprocess *subprocess,
GSubprocessLauncher *launcher);
G_END_DECLS
#endif