2014-11-22 07:21:33 +01:00
|
|
|
/*
|
|
|
|
* This file is part of mpv.
|
|
|
|
*
|
Relicense some non-MPlayer source files to LGPL 2.1 or later
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.
There are probably more files to which this applies, but I'm being
conservative here.
A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).
common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.
codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.
From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).
misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.
screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
2016-01-19 18:36:06 +01:00
|
|
|
* mpv 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.
|
2014-11-22 07:21:33 +01:00
|
|
|
*
|
|
|
|
* mpv 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
|
Relicense some non-MPlayer source files to LGPL 2.1 or later
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.
There are probably more files to which this applies, but I'm being
conservative here.
A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).
common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.
codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.
From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).
misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.
screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
2016-01-19 18:36:06 +01:00
|
|
|
* GNU Lesser General Public License for more details.
|
2014-11-22 07:21:33 +01:00
|
|
|
*
|
Relicense some non-MPlayer source files to LGPL 2.1 or later
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.
There are probably more files to which this applies, but I'm being
conservative here.
A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).
common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.
codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.
From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).
misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.
screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
2016-01-19 18:36:06 +01:00
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2014-11-22 07:21:33 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <poll.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
#include <sys/types.h>
|
|
|
|
#include <sys/wait.h>
|
2015-04-15 22:42:20 +02:00
|
|
|
#include <fcntl.h>
|
2014-11-22 07:21:33 +01:00
|
|
|
#include <errno.h>
|
|
|
|
#include <signal.h>
|
|
|
|
|
2014-11-22 14:38:58 +01:00
|
|
|
#include "osdep/subprocess.h"
|
|
|
|
|
2014-11-22 07:21:33 +01:00
|
|
|
#include "common/common.h"
|
2018-05-17 20:58:49 +02:00
|
|
|
#include "misc/thread_tools.h"
|
|
|
|
#include "osdep/io.h"
|
2014-11-22 14:38:58 +01:00
|
|
|
#include "stream/stream.h"
|
2014-11-22 07:21:33 +01:00
|
|
|
|
|
|
|
extern char **environ;
|
|
|
|
|
2021-12-19 14:17:54 +01:00
|
|
|
#ifdef SIGRTMAX
|
|
|
|
#define SIGNAL_MAX SIGRTMAX
|
|
|
|
#else
|
|
|
|
#define SIGNAL_MAX 32
|
|
|
|
#endif
|
|
|
|
|
2017-06-27 14:22:28 +02:00
|
|
|
#define SAFE_CLOSE(fd) do { if ((fd) >= 0) close((fd)); (fd) = -1; } while (0)
|
|
|
|
|
subprocess: replace posix_spawnp() with fork()
This code runs posix_spawnp() within a fork() in some cases, in order to
"disown" processes which are meant as being started detached. But
posix_spawnp() is not marked as async-signal-safe, so what we do is not
allowed. It could for example cause deadlocks, depending on
implementation and luck at runtime. Turns out posix_spawnp() is useless
crap.
Replace it with "classic" fork() to ensure correctness.
We could probably use another mechanism to start a process "disowned"
than doing a double-fork(). The only problem with "disowning" a process
is calling setsid() (which posix_spawnp() didn't support, but maybe will
in newer revisions), and removing as as parent from the child process
(the double-fork() will make PID 1 the parent). But there is no good way
to either remove us as parent, or to "reap" the PID in a way that is
safe and less of a mess than the current code. This is because
POSIX/UNIX is a miserable heap of shit. (Less shit than "alternatives"
like win32, no doubt.)
Because POSIX/UNIX is a miserable heap of shit, execvp() is also not
specified as async-signal-safe. It's funny how you can run a full
fledged HTTP server in an async-signal-safe context, but not start a
shitty damn process. Unix is really, really, really extremely bad at
this process management stuff. So we reimplement execvp() in an
async-signal-safe way.
The new code assumes that CLOEXEC is a thing. Since POSIX/UNIX is such a
heap of shit, O_CLOEXEC and FD_CLOEXEC were (probably) added at
different times, but both must be present. io.h defines them to 0 if
they don't exist, and in this case the code will error out at runtime.
Surely we could do without CLOEXEC via fallback, but I'll do that only
if at least 1 bug is reported wrt. this issue.
The idea how to report exec() failure or success is from musl. The way
as_execvpe() is also inspired by musl (for example, the list of error
codes that should make it fail is the same as in musl's code).
2020-05-15 16:13:28 +02:00
|
|
|
// Async-signal-safe execvpe(). POSIX does not list it as async-signal-safe
|
|
|
|
// (POSIX is such a joke), so do it manually. While in theory the searching is
|
|
|
|
// apparently implementation dependent and not exposed (because POSIX is a
|
|
|
|
// joke?), the expected rules are still relatively simple.
|
|
|
|
// Doesn't set errno correctly.
|
|
|
|
// Somewhat inspired by musl's src/process/execvp.c.
|
|
|
|
static int as_execvpe(const char *path, const char *file, char *const argv[],
|
|
|
|
char *const envp[])
|
|
|
|
{
|
|
|
|
if (strchr(file, '/') || !file[0])
|
|
|
|
return execve(file, argv, envp);
|
|
|
|
|
|
|
|
size_t flen = strlen(file);
|
|
|
|
while (path && path[0]) {
|
|
|
|
size_t plen = strcspn(path, ":");
|
|
|
|
// Ignore paths that are too long.
|
|
|
|
char fn[PATH_MAX];
|
|
|
|
if (plen + 1 + flen + 1 < sizeof(fn)) {
|
|
|
|
memcpy(fn, path, plen);
|
|
|
|
fn[plen] = '/';
|
|
|
|
memcpy(fn + plen + 1, file, flen + 1);
|
|
|
|
execve(fn, argv, envp);
|
|
|
|
if (errno != EACCES && errno != ENOENT && errno != ENOTDIR)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
path += plen + (path[plen] == ':' ? 1 : 0);
|
|
|
|
}
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2021-12-19 14:17:54 +01:00
|
|
|
// In the child process, resets the signal mask to defaults. Also clears any
|
|
|
|
// signal handlers first so nothing funny happens.
|
|
|
|
static void reset_signals_child(void)
|
|
|
|
{
|
|
|
|
struct sigaction sa = { 0 };
|
|
|
|
sigset_t sigmask;
|
|
|
|
sa.sa_handler = SIG_DFL;
|
|
|
|
sigemptyset(&sigmask);
|
|
|
|
|
|
|
|
for (int nr = 1; nr < SIGNAL_MAX; nr++)
|
|
|
|
sigaction(nr, &sa, NULL);
|
|
|
|
sigprocmask(SIG_SETMASK, &sigmask, NULL);
|
|
|
|
}
|
|
|
|
|
subprocess: replace posix_spawnp() with fork()
This code runs posix_spawnp() within a fork() in some cases, in order to
"disown" processes which are meant as being started detached. But
posix_spawnp() is not marked as async-signal-safe, so what we do is not
allowed. It could for example cause deadlocks, depending on
implementation and luck at runtime. Turns out posix_spawnp() is useless
crap.
Replace it with "classic" fork() to ensure correctness.
We could probably use another mechanism to start a process "disowned"
than doing a double-fork(). The only problem with "disowning" a process
is calling setsid() (which posix_spawnp() didn't support, but maybe will
in newer revisions), and removing as as parent from the child process
(the double-fork() will make PID 1 the parent). But there is no good way
to either remove us as parent, or to "reap" the PID in a way that is
safe and less of a mess than the current code. This is because
POSIX/UNIX is a miserable heap of shit. (Less shit than "alternatives"
like win32, no doubt.)
Because POSIX/UNIX is a miserable heap of shit, execvp() is also not
specified as async-signal-safe. It's funny how you can run a full
fledged HTTP server in an async-signal-safe context, but not start a
shitty damn process. Unix is really, really, really extremely bad at
this process management stuff. So we reimplement execvp() in an
async-signal-safe way.
The new code assumes that CLOEXEC is a thing. Since POSIX/UNIX is such a
heap of shit, O_CLOEXEC and FD_CLOEXEC were (probably) added at
different times, but both must be present. io.h defines them to 0 if
they don't exist, and in this case the code will error out at runtime.
Surely we could do without CLOEXEC via fallback, but I'll do that only
if at least 1 bug is reported wrt. this issue.
The idea how to report exec() failure or success is from musl. The way
as_execvpe() is also inspired by musl (for example, the list of error
codes that should make it fail is the same as in musl's code).
2020-05-15 16:13:28 +02:00
|
|
|
// Returns 0 on any error, valid PID on success.
|
|
|
|
// This function must be async-signal-safe, as it may be called from a fork().
|
|
|
|
static pid_t spawn_process(const char *path, struct mp_subprocess_opts *opts,
|
|
|
|
int src_fds[])
|
|
|
|
{
|
|
|
|
int p[2] = {-1, -1};
|
|
|
|
pid_t fres = 0;
|
|
|
|
sigset_t sigmask, oldmask;
|
|
|
|
sigfillset(&sigmask);
|
|
|
|
pthread_sigmask(SIG_BLOCK, &sigmask, &oldmask);
|
|
|
|
|
|
|
|
// We setup a communication pipe to signal failure. Since the child calls
|
|
|
|
// exec() and becomes the calling process, we don't know if or when the
|
|
|
|
// child process successfully ran exec() just from the PID.
|
|
|
|
// Use a CLOEXEC pipe to detect whether exec() was used. Obviously it will
|
|
|
|
// be closed if exec() succeeds, and an error is written if not.
|
|
|
|
// There are also some things further below in the code that need CLOEXEC.
|
|
|
|
if (mp_make_cloexec_pipe(p) < 0)
|
|
|
|
goto done;
|
|
|
|
// Check whether CLOEXEC is really set. Important for correct operation.
|
|
|
|
int p_flags = fcntl(p[0], F_GETFD);
|
|
|
|
if (p_flags == -1 || !FD_CLOEXEC || !(p_flags & FD_CLOEXEC))
|
|
|
|
goto done; // require CLOEXEC; unknown if fallback would be worth it
|
|
|
|
|
|
|
|
fres = fork();
|
|
|
|
if (fres < 0) {
|
|
|
|
fres = 0;
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
if (fres == 0) {
|
|
|
|
// child
|
2021-12-19 14:17:54 +01:00
|
|
|
reset_signals_child();
|
subprocess: replace posix_spawnp() with fork()
This code runs posix_spawnp() within a fork() in some cases, in order to
"disown" processes which are meant as being started detached. But
posix_spawnp() is not marked as async-signal-safe, so what we do is not
allowed. It could for example cause deadlocks, depending on
implementation and luck at runtime. Turns out posix_spawnp() is useless
crap.
Replace it with "classic" fork() to ensure correctness.
We could probably use another mechanism to start a process "disowned"
than doing a double-fork(). The only problem with "disowning" a process
is calling setsid() (which posix_spawnp() didn't support, but maybe will
in newer revisions), and removing as as parent from the child process
(the double-fork() will make PID 1 the parent). But there is no good way
to either remove us as parent, or to "reap" the PID in a way that is
safe and less of a mess than the current code. This is because
POSIX/UNIX is a miserable heap of shit. (Less shit than "alternatives"
like win32, no doubt.)
Because POSIX/UNIX is a miserable heap of shit, execvp() is also not
specified as async-signal-safe. It's funny how you can run a full
fledged HTTP server in an async-signal-safe context, but not start a
shitty damn process. Unix is really, really, really extremely bad at
this process management stuff. So we reimplement execvp() in an
async-signal-safe way.
The new code assumes that CLOEXEC is a thing. Since POSIX/UNIX is such a
heap of shit, O_CLOEXEC and FD_CLOEXEC were (probably) added at
different times, but both must be present. io.h defines them to 0 if
they don't exist, and in this case the code will error out at runtime.
Surely we could do without CLOEXEC via fallback, but I'll do that only
if at least 1 bug is reported wrt. this issue.
The idea how to report exec() failure or success is from musl. The way
as_execvpe() is also inspired by musl (for example, the list of error
codes that should make it fail is the same as in musl's code).
2020-05-15 16:13:28 +02:00
|
|
|
|
|
|
|
for (int n = 0; n < opts->num_fds; n++) {
|
|
|
|
if (src_fds[n] == opts->fds[n].fd) {
|
|
|
|
int flags = fcntl(opts->fds[n].fd, F_GETFD);
|
|
|
|
if (flags == -1)
|
|
|
|
goto child_failed;
|
|
|
|
flags &= ~(unsigned)FD_CLOEXEC;
|
|
|
|
if (fcntl(opts->fds[n].fd, F_SETFD, flags) == -1)
|
|
|
|
goto child_failed;
|
|
|
|
} else if (dup2(src_fds[n], opts->fds[n].fd) < 0) {
|
|
|
|
goto child_failed;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
as_execvpe(path, opts->exe, opts->args, opts->env ? opts->env : environ);
|
|
|
|
|
|
|
|
child_failed:
|
2023-10-23 16:04:59 +02:00
|
|
|
(void)write(p[1], &(char){1}, 1); // shouldn't be able to fail
|
subprocess: replace posix_spawnp() with fork()
This code runs posix_spawnp() within a fork() in some cases, in order to
"disown" processes which are meant as being started detached. But
posix_spawnp() is not marked as async-signal-safe, so what we do is not
allowed. It could for example cause deadlocks, depending on
implementation and luck at runtime. Turns out posix_spawnp() is useless
crap.
Replace it with "classic" fork() to ensure correctness.
We could probably use another mechanism to start a process "disowned"
than doing a double-fork(). The only problem with "disowning" a process
is calling setsid() (which posix_spawnp() didn't support, but maybe will
in newer revisions), and removing as as parent from the child process
(the double-fork() will make PID 1 the parent). But there is no good way
to either remove us as parent, or to "reap" the PID in a way that is
safe and less of a mess than the current code. This is because
POSIX/UNIX is a miserable heap of shit. (Less shit than "alternatives"
like win32, no doubt.)
Because POSIX/UNIX is a miserable heap of shit, execvp() is also not
specified as async-signal-safe. It's funny how you can run a full
fledged HTTP server in an async-signal-safe context, but not start a
shitty damn process. Unix is really, really, really extremely bad at
this process management stuff. So we reimplement execvp() in an
async-signal-safe way.
The new code assumes that CLOEXEC is a thing. Since POSIX/UNIX is such a
heap of shit, O_CLOEXEC and FD_CLOEXEC were (probably) added at
different times, but both must be present. io.h defines them to 0 if
they don't exist, and in this case the code will error out at runtime.
Surely we could do without CLOEXEC via fallback, but I'll do that only
if at least 1 bug is reported wrt. this issue.
The idea how to report exec() failure or success is from musl. The way
as_execvpe() is also inspired by musl (for example, the list of error
codes that should make it fail is the same as in musl's code).
2020-05-15 16:13:28 +02:00
|
|
|
_exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
SAFE_CLOSE(p[1]);
|
|
|
|
|
|
|
|
int r;
|
|
|
|
do {
|
|
|
|
r = read(p[0], &(char){0}, 1);
|
|
|
|
} while (r < 0 && errno == EINTR);
|
|
|
|
|
|
|
|
// If exec()ing child failed, collect it immediately.
|
|
|
|
if (r != 0) {
|
|
|
|
while (waitpid(fres, &(int){0}, 0) < 0 && errno == EINTR) {}
|
|
|
|
fres = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
done:
|
|
|
|
pthread_sigmask(SIG_SETMASK, &oldmask, NULL);
|
|
|
|
SAFE_CLOSE(p[0]);
|
|
|
|
SAFE_CLOSE(p[1]);
|
|
|
|
|
|
|
|
return fres;
|
|
|
|
}
|
|
|
|
|
2020-02-16 21:27:34 +01:00
|
|
|
void mp_subprocess2(struct mp_subprocess_opts *opts,
|
|
|
|
struct mp_subprocess_result *res)
|
2014-11-22 07:21:33 +01:00
|
|
|
{
|
|
|
|
int status = -1;
|
2020-02-16 21:27:34 +01:00
|
|
|
int comm_pipe[MP_SUBPROCESS_MAX_FDS][2];
|
subprocess: replace posix_spawnp() with fork()
This code runs posix_spawnp() within a fork() in some cases, in order to
"disown" processes which are meant as being started detached. But
posix_spawnp() is not marked as async-signal-safe, so what we do is not
allowed. It could for example cause deadlocks, depending on
implementation and luck at runtime. Turns out posix_spawnp() is useless
crap.
Replace it with "classic" fork() to ensure correctness.
We could probably use another mechanism to start a process "disowned"
than doing a double-fork(). The only problem with "disowning" a process
is calling setsid() (which posix_spawnp() didn't support, but maybe will
in newer revisions), and removing as as parent from the child process
(the double-fork() will make PID 1 the parent). But there is no good way
to either remove us as parent, or to "reap" the PID in a way that is
safe and less of a mess than the current code. This is because
POSIX/UNIX is a miserable heap of shit. (Less shit than "alternatives"
like win32, no doubt.)
Because POSIX/UNIX is a miserable heap of shit, execvp() is also not
specified as async-signal-safe. It's funny how you can run a full
fledged HTTP server in an async-signal-safe context, but not start a
shitty damn process. Unix is really, really, really extremely bad at
this process management stuff. So we reimplement execvp() in an
async-signal-safe way.
The new code assumes that CLOEXEC is a thing. Since POSIX/UNIX is such a
heap of shit, O_CLOEXEC and FD_CLOEXEC were (probably) added at
different times, but both must be present. io.h defines them to 0 if
they don't exist, and in this case the code will error out at runtime.
Surely we could do without CLOEXEC via fallback, but I'll do that only
if at least 1 bug is reported wrt. this issue.
The idea how to report exec() failure or success is from musl. The way
as_execvpe() is also inspired by musl (for example, the list of error
codes that should make it fail is the same as in musl's code).
2020-05-15 16:13:28 +02:00
|
|
|
int src_fds[MP_SUBPROCESS_MAX_FDS];
|
2015-04-15 22:42:20 +02:00
|
|
|
int devnull = -1;
|
subprocess: implement proper detached processes on POSIX
The previous method for this sucked: for every launched detached
process, it started a thread, which then would leak if the launched
process didn't end before the player uninitialized. This was very racy
(although I bet the race condition wouldn't trigger in a 100 years), and
wasteful (threads aren't a cheap resource).
Implement it for POSIX directly. posix_spawn() has no direct support for
this, so we need to do it ourselves with fork(). We could probably do it
without fork(), and attempt to collect the PID in another thread. But
then we'd either have a waiting thread again, or we'd need to do an
unsafe waitpid(-1, ...) call. (POSIX process management sucks so badly,
how did they even manage this. Hopefully I'm just missing something, but
I'm not.) So now we depend on both posix_spawn() _and_ fork(), isn't it
fun?
Also call setsid(), to essentially detach the child process from the
terminal. (Otherwise it can receive various signals from the terminal,
which is probably not what you want.) posix_spawn() adds
POSIX_SPAWN_SETSID in newer POSIX releases, but we don't want to rely on
this yet.
The posix_spawnp() call is duplicated, but this is better than somehow
trying to unify the code paths.
Only somewhat tested, so enjoy the bugs.
2020-02-16 21:57:17 +01:00
|
|
|
pid_t pid = 0;
|
2015-06-27 21:08:55 +02:00
|
|
|
bool spawned = false;
|
|
|
|
bool killed_by_us = false;
|
2020-02-16 21:27:34 +01:00
|
|
|
int cancel_fd = -1;
|
subprocess: replace posix_spawnp() with fork()
This code runs posix_spawnp() within a fork() in some cases, in order to
"disown" processes which are meant as being started detached. But
posix_spawnp() is not marked as async-signal-safe, so what we do is not
allowed. It could for example cause deadlocks, depending on
implementation and luck at runtime. Turns out posix_spawnp() is useless
crap.
Replace it with "classic" fork() to ensure correctness.
We could probably use another mechanism to start a process "disowned"
than doing a double-fork(). The only problem with "disowning" a process
is calling setsid() (which posix_spawnp() didn't support, but maybe will
in newer revisions), and removing as as parent from the child process
(the double-fork() will make PID 1 the parent). But there is no good way
to either remove us as parent, or to "reap" the PID in a way that is
safe and less of a mess than the current code. This is because
POSIX/UNIX is a miserable heap of shit. (Less shit than "alternatives"
like win32, no doubt.)
Because POSIX/UNIX is a miserable heap of shit, execvp() is also not
specified as async-signal-safe. It's funny how you can run a full
fledged HTTP server in an async-signal-safe context, but not start a
shitty damn process. Unix is really, really, really extremely bad at
this process management stuff. So we reimplement execvp() in an
async-signal-safe way.
The new code assumes that CLOEXEC is a thing. Since POSIX/UNIX is such a
heap of shit, O_CLOEXEC and FD_CLOEXEC were (probably) added at
different times, but both must be present. io.h defines them to 0 if
they don't exist, and in this case the code will error out at runtime.
Surely we could do without CLOEXEC via fallback, but I'll do that only
if at least 1 bug is reported wrt. this issue.
The idea how to report exec() failure or success is from musl. The way
as_execvpe() is also inspired by musl (for example, the list of error
codes that should make it fail is the same as in musl's code).
2020-05-15 16:13:28 +02:00
|
|
|
char *path = getenv("PATH");
|
2020-05-24 22:44:56 +02:00
|
|
|
if (!path)
|
|
|
|
path = ""; // failure, who cares
|
2014-11-22 07:21:33 +01:00
|
|
|
|
2020-02-16 21:27:34 +01:00
|
|
|
*res = (struct mp_subprocess_result){0};
|
|
|
|
|
|
|
|
for (int n = 0; n < opts->num_fds; n++)
|
|
|
|
comm_pipe[n][0] = comm_pipe[n][1] = -1;
|
|
|
|
|
|
|
|
if (opts->cancel) {
|
|
|
|
cancel_fd = mp_cancel_get_fd(opts->cancel);
|
|
|
|
if (cancel_fd < 0)
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (int n = 0; n < opts->num_fds; n++) {
|
2020-08-16 02:54:44 +02:00
|
|
|
assert(!(opts->fds[n].on_read && opts->fds[n].on_write));
|
|
|
|
|
2020-02-16 21:27:34 +01:00
|
|
|
if (opts->fds[n].on_read && mp_make_cloexec_pipe(comm_pipe[n]) < 0)
|
|
|
|
goto done;
|
2020-08-16 02:54:44 +02:00
|
|
|
|
|
|
|
if (opts->fds[n].on_write || opts->fds[n].write_buf) {
|
|
|
|
assert(opts->fds[n].on_write && opts->fds[n].write_buf);
|
|
|
|
if (mp_make_cloexec_pipe(comm_pipe[n]) < 0)
|
|
|
|
goto done;
|
|
|
|
MPSWAP(int, comm_pipe[n][0], comm_pipe[n][1]);
|
|
|
|
|
|
|
|
struct sigaction sa = {.sa_handler = SIG_IGN, .sa_flags = SA_RESTART};
|
|
|
|
sigfillset(&sa.sa_mask);
|
|
|
|
sigaction(SIGPIPE, &sa, NULL);
|
|
|
|
}
|
2020-02-16 21:27:34 +01:00
|
|
|
}
|
2014-11-22 07:21:33 +01:00
|
|
|
|
2015-04-15 22:42:20 +02:00
|
|
|
devnull = open("/dev/null", O_RDONLY | O_CLOEXEC);
|
|
|
|
if (devnull < 0)
|
|
|
|
goto done;
|
|
|
|
|
2020-02-16 21:27:34 +01:00
|
|
|
// redirect FDs
|
|
|
|
for (int n = 0; n < opts->num_fds; n++) {
|
|
|
|
int src_fd = devnull;
|
|
|
|
if (comm_pipe[n][1] >= 0)
|
|
|
|
src_fd = comm_pipe[n][1];
|
|
|
|
if (opts->fds[n].src_fd >= 0)
|
|
|
|
src_fd = opts->fds[n].src_fd;
|
subprocess: replace posix_spawnp() with fork()
This code runs posix_spawnp() within a fork() in some cases, in order to
"disown" processes which are meant as being started detached. But
posix_spawnp() is not marked as async-signal-safe, so what we do is not
allowed. It could for example cause deadlocks, depending on
implementation and luck at runtime. Turns out posix_spawnp() is useless
crap.
Replace it with "classic" fork() to ensure correctness.
We could probably use another mechanism to start a process "disowned"
than doing a double-fork(). The only problem with "disowning" a process
is calling setsid() (which posix_spawnp() didn't support, but maybe will
in newer revisions), and removing as as parent from the child process
(the double-fork() will make PID 1 the parent). But there is no good way
to either remove us as parent, or to "reap" the PID in a way that is
safe and less of a mess than the current code. This is because
POSIX/UNIX is a miserable heap of shit. (Less shit than "alternatives"
like win32, no doubt.)
Because POSIX/UNIX is a miserable heap of shit, execvp() is also not
specified as async-signal-safe. It's funny how you can run a full
fledged HTTP server in an async-signal-safe context, but not start a
shitty damn process. Unix is really, really, really extremely bad at
this process management stuff. So we reimplement execvp() in an
async-signal-safe way.
The new code assumes that CLOEXEC is a thing. Since POSIX/UNIX is such a
heap of shit, O_CLOEXEC and FD_CLOEXEC were (probably) added at
different times, but both must be present. io.h defines them to 0 if
they don't exist, and in this case the code will error out at runtime.
Surely we could do without CLOEXEC via fallback, but I'll do that only
if at least 1 bug is reported wrt. this issue.
The idea how to report exec() failure or success is from musl. The way
as_execvpe() is also inspired by musl (for example, the list of error
codes that should make it fail is the same as in musl's code).
2020-05-15 16:13:28 +02:00
|
|
|
src_fds[n] = src_fd;
|
2020-02-16 21:27:34 +01:00
|
|
|
}
|
|
|
|
|
subprocess: implement proper detached processes on POSIX
The previous method for this sucked: for every launched detached
process, it started a thread, which then would leak if the launched
process didn't end before the player uninitialized. This was very racy
(although I bet the race condition wouldn't trigger in a 100 years), and
wasteful (threads aren't a cheap resource).
Implement it for POSIX directly. posix_spawn() has no direct support for
this, so we need to do it ourselves with fork(). We could probably do it
without fork(), and attempt to collect the PID in another thread. But
then we'd either have a waiting thread again, or we'd need to do an
unsafe waitpid(-1, ...) call. (POSIX process management sucks so badly,
how did they even manage this. Hopefully I'm just missing something, but
I'm not.) So now we depend on both posix_spawn() _and_ fork(), isn't it
fun?
Also call setsid(), to essentially detach the child process from the
terminal. (Otherwise it can receive various signals from the terminal,
which is probably not what you want.) posix_spawn() adds
POSIX_SPAWN_SETSID in newer POSIX releases, but we don't want to rely on
this yet.
The posix_spawnp() call is duplicated, but this is better than somehow
trying to unify the code paths.
Only somewhat tested, so enjoy the bugs.
2020-02-16 21:57:17 +01:00
|
|
|
if (opts->detach) {
|
|
|
|
// If we run it detached, we fork a child to start the process; then
|
|
|
|
// it exits immediately, letting PID 1 inherit it. So we don't need
|
|
|
|
// anything else to collect these child PIDs.
|
|
|
|
sigset_t sigmask, oldmask;
|
|
|
|
sigfillset(&sigmask);
|
|
|
|
pthread_sigmask(SIG_BLOCK, &sigmask, &oldmask);
|
|
|
|
pid_t fres = fork();
|
|
|
|
if (fres < 0)
|
|
|
|
goto done;
|
|
|
|
if (fres == 0) {
|
|
|
|
// child
|
|
|
|
setsid();
|
subprocess: replace posix_spawnp() with fork()
This code runs posix_spawnp() within a fork() in some cases, in order to
"disown" processes which are meant as being started detached. But
posix_spawnp() is not marked as async-signal-safe, so what we do is not
allowed. It could for example cause deadlocks, depending on
implementation and luck at runtime. Turns out posix_spawnp() is useless
crap.
Replace it with "classic" fork() to ensure correctness.
We could probably use another mechanism to start a process "disowned"
than doing a double-fork(). The only problem with "disowning" a process
is calling setsid() (which posix_spawnp() didn't support, but maybe will
in newer revisions), and removing as as parent from the child process
(the double-fork() will make PID 1 the parent). But there is no good way
to either remove us as parent, or to "reap" the PID in a way that is
safe and less of a mess than the current code. This is because
POSIX/UNIX is a miserable heap of shit. (Less shit than "alternatives"
like win32, no doubt.)
Because POSIX/UNIX is a miserable heap of shit, execvp() is also not
specified as async-signal-safe. It's funny how you can run a full
fledged HTTP server in an async-signal-safe context, but not start a
shitty damn process. Unix is really, really, really extremely bad at
this process management stuff. So we reimplement execvp() in an
async-signal-safe way.
The new code assumes that CLOEXEC is a thing. Since POSIX/UNIX is such a
heap of shit, O_CLOEXEC and FD_CLOEXEC were (probably) added at
different times, but both must be present. io.h defines them to 0 if
they don't exist, and in this case the code will error out at runtime.
Surely we could do without CLOEXEC via fallback, but I'll do that only
if at least 1 bug is reported wrt. this issue.
The idea how to report exec() failure or success is from musl. The way
as_execvpe() is also inspired by musl (for example, the list of error
codes that should make it fail is the same as in musl's code).
2020-05-15 16:13:28 +02:00
|
|
|
if (!spawn_process(path, opts, src_fds))
|
subprocess: implement proper detached processes on POSIX
The previous method for this sucked: for every launched detached
process, it started a thread, which then would leak if the launched
process didn't end before the player uninitialized. This was very racy
(although I bet the race condition wouldn't trigger in a 100 years), and
wasteful (threads aren't a cheap resource).
Implement it for POSIX directly. posix_spawn() has no direct support for
this, so we need to do it ourselves with fork(). We could probably do it
without fork(), and attempt to collect the PID in another thread. But
then we'd either have a waiting thread again, or we'd need to do an
unsafe waitpid(-1, ...) call. (POSIX process management sucks so badly,
how did they even manage this. Hopefully I'm just missing something, but
I'm not.) So now we depend on both posix_spawn() _and_ fork(), isn't it
fun?
Also call setsid(), to essentially detach the child process from the
terminal. (Otherwise it can receive various signals from the terminal,
which is probably not what you want.) posix_spawn() adds
POSIX_SPAWN_SETSID in newer POSIX releases, but we don't want to rely on
this yet.
The posix_spawnp() call is duplicated, but this is better than somehow
trying to unify the code paths.
Only somewhat tested, so enjoy the bugs.
2020-02-16 21:57:17 +01:00
|
|
|
_exit(1);
|
|
|
|
_exit(0);
|
|
|
|
}
|
|
|
|
pthread_sigmask(SIG_SETMASK, &oldmask, NULL);
|
|
|
|
int child_status = 0;
|
|
|
|
while (waitpid(fres, &child_status, 0) < 0 && errno == EINTR) {}
|
|
|
|
if (!WIFEXITED(child_status) || WEXITSTATUS(child_status) != 0)
|
|
|
|
goto done;
|
|
|
|
} else {
|
subprocess: replace posix_spawnp() with fork()
This code runs posix_spawnp() within a fork() in some cases, in order to
"disown" processes which are meant as being started detached. But
posix_spawnp() is not marked as async-signal-safe, so what we do is not
allowed. It could for example cause deadlocks, depending on
implementation and luck at runtime. Turns out posix_spawnp() is useless
crap.
Replace it with "classic" fork() to ensure correctness.
We could probably use another mechanism to start a process "disowned"
than doing a double-fork(). The only problem with "disowning" a process
is calling setsid() (which posix_spawnp() didn't support, but maybe will
in newer revisions), and removing as as parent from the child process
(the double-fork() will make PID 1 the parent). But there is no good way
to either remove us as parent, or to "reap" the PID in a way that is
safe and less of a mess than the current code. This is because
POSIX/UNIX is a miserable heap of shit. (Less shit than "alternatives"
like win32, no doubt.)
Because POSIX/UNIX is a miserable heap of shit, execvp() is also not
specified as async-signal-safe. It's funny how you can run a full
fledged HTTP server in an async-signal-safe context, but not start a
shitty damn process. Unix is really, really, really extremely bad at
this process management stuff. So we reimplement execvp() in an
async-signal-safe way.
The new code assumes that CLOEXEC is a thing. Since POSIX/UNIX is such a
heap of shit, O_CLOEXEC and FD_CLOEXEC were (probably) added at
different times, but both must be present. io.h defines them to 0 if
they don't exist, and in this case the code will error out at runtime.
Surely we could do without CLOEXEC via fallback, but I'll do that only
if at least 1 bug is reported wrt. this issue.
The idea how to report exec() failure or success is from musl. The way
as_execvpe() is also inspired by musl (for example, the list of error
codes that should make it fail is the same as in musl's code).
2020-05-15 16:13:28 +02:00
|
|
|
pid = spawn_process(path, opts, src_fds);
|
|
|
|
if (!pid)
|
subprocess: implement proper detached processes on POSIX
The previous method for this sucked: for every launched detached
process, it started a thread, which then would leak if the launched
process didn't end before the player uninitialized. This was very racy
(although I bet the race condition wouldn't trigger in a 100 years), and
wasteful (threads aren't a cheap resource).
Implement it for POSIX directly. posix_spawn() has no direct support for
this, so we need to do it ourselves with fork(). We could probably do it
without fork(), and attempt to collect the PID in another thread. But
then we'd either have a waiting thread again, or we'd need to do an
unsafe waitpid(-1, ...) call. (POSIX process management sucks so badly,
how did they even manage this. Hopefully I'm just missing something, but
I'm not.) So now we depend on both posix_spawn() _and_ fork(), isn't it
fun?
Also call setsid(), to essentially detach the child process from the
terminal. (Otherwise it can receive various signals from the terminal,
which is probably not what you want.) posix_spawn() adds
POSIX_SPAWN_SETSID in newer POSIX releases, but we don't want to rely on
this yet.
The posix_spawnp() call is duplicated, but this is better than somehow
trying to unify the code paths.
Only somewhat tested, so enjoy the bugs.
2020-02-16 21:57:17 +01:00
|
|
|
goto done;
|
2014-11-22 07:21:33 +01:00
|
|
|
}
|
|
|
|
|
subprocess: replace posix_spawnp() with fork()
This code runs posix_spawnp() within a fork() in some cases, in order to
"disown" processes which are meant as being started detached. But
posix_spawnp() is not marked as async-signal-safe, so what we do is not
allowed. It could for example cause deadlocks, depending on
implementation and luck at runtime. Turns out posix_spawnp() is useless
crap.
Replace it with "classic" fork() to ensure correctness.
We could probably use another mechanism to start a process "disowned"
than doing a double-fork(). The only problem with "disowning" a process
is calling setsid() (which posix_spawnp() didn't support, but maybe will
in newer revisions), and removing as as parent from the child process
(the double-fork() will make PID 1 the parent). But there is no good way
to either remove us as parent, or to "reap" the PID in a way that is
safe and less of a mess than the current code. This is because
POSIX/UNIX is a miserable heap of shit. (Less shit than "alternatives"
like win32, no doubt.)
Because POSIX/UNIX is a miserable heap of shit, execvp() is also not
specified as async-signal-safe. It's funny how you can run a full
fledged HTTP server in an async-signal-safe context, but not start a
shitty damn process. Unix is really, really, really extremely bad at
this process management stuff. So we reimplement execvp() in an
async-signal-safe way.
The new code assumes that CLOEXEC is a thing. Since POSIX/UNIX is such a
heap of shit, O_CLOEXEC and FD_CLOEXEC were (probably) added at
different times, but both must be present. io.h defines them to 0 if
they don't exist, and in this case the code will error out at runtime.
Surely we could do without CLOEXEC via fallback, but I'll do that only
if at least 1 bug is reported wrt. this issue.
The idea how to report exec() failure or success is from musl. The way
as_execvpe() is also inspired by musl (for example, the list of error
codes that should make it fail is the same as in musl's code).
2020-05-15 16:13:28 +02:00
|
|
|
spawned = true;
|
|
|
|
|
2020-02-16 21:27:34 +01:00
|
|
|
for (int n = 0; n < opts->num_fds; n++)
|
|
|
|
SAFE_CLOSE(comm_pipe[n][1]);
|
2017-06-27 14:22:28 +02:00
|
|
|
SAFE_CLOSE(devnull);
|
2014-11-22 07:21:33 +01:00
|
|
|
|
2020-02-16 21:27:34 +01:00
|
|
|
while (1) {
|
|
|
|
struct pollfd fds[MP_SUBPROCESS_MAX_FDS + 1];
|
|
|
|
int map_fds[MP_SUBPROCESS_MAX_FDS + 1];
|
|
|
|
int num_fds = 0;
|
|
|
|
for (int n = 0; n < opts->num_fds; n++) {
|
|
|
|
if (comm_pipe[n][0] >= 0) {
|
|
|
|
map_fds[num_fds] = n;
|
|
|
|
fds[num_fds++] = (struct pollfd){
|
2020-08-16 02:54:44 +02:00
|
|
|
.events = opts->fds[n].on_read ? POLLIN : POLLOUT,
|
2020-02-16 21:27:34 +01:00
|
|
|
.fd = comm_pipe[n][0],
|
|
|
|
};
|
2014-11-22 07:21:33 +01:00
|
|
|
}
|
|
|
|
}
|
2020-02-16 21:27:34 +01:00
|
|
|
if (!num_fds)
|
|
|
|
break;
|
|
|
|
if (cancel_fd >= 0) {
|
|
|
|
map_fds[num_fds] = -1;
|
|
|
|
fds[num_fds++] = (struct pollfd){.events = POLLIN, .fd = cancel_fd};
|
|
|
|
}
|
|
|
|
|
|
|
|
if (poll(fds, num_fds, -1) < 0 && errno != EINTR)
|
2014-11-22 07:21:33 +01:00
|
|
|
break;
|
2020-02-16 21:27:34 +01:00
|
|
|
|
|
|
|
for (int idx = 0; idx < num_fds; idx++) {
|
|
|
|
if (fds[idx].revents) {
|
|
|
|
int n = map_fds[idx];
|
|
|
|
if (n < 0) {
|
|
|
|
// cancel_fd
|
subprocess: implement proper detached processes on POSIX
The previous method for this sucked: for every launched detached
process, it started a thread, which then would leak if the launched
process didn't end before the player uninitialized. This was very racy
(although I bet the race condition wouldn't trigger in a 100 years), and
wasteful (threads aren't a cheap resource).
Implement it for POSIX directly. posix_spawn() has no direct support for
this, so we need to do it ourselves with fork(). We could probably do it
without fork(), and attempt to collect the PID in another thread. But
then we'd either have a waiting thread again, or we'd need to do an
unsafe waitpid(-1, ...) call. (POSIX process management sucks so badly,
how did they even manage this. Hopefully I'm just missing something, but
I'm not.) So now we depend on both posix_spawn() _and_ fork(), isn't it
fun?
Also call setsid(), to essentially detach the child process from the
terminal. (Otherwise it can receive various signals from the terminal,
which is probably not what you want.) posix_spawn() adds
POSIX_SPAWN_SETSID in newer POSIX releases, but we don't want to rely on
this yet.
The posix_spawnp() call is duplicated, but this is better than somehow
trying to unify the code paths.
Only somewhat tested, so enjoy the bugs.
2020-02-16 21:57:17 +01:00
|
|
|
if (pid)
|
|
|
|
kill(pid, SIGKILL);
|
2020-02-16 21:27:34 +01:00
|
|
|
killed_by_us = true;
|
2024-02-10 19:16:16 +01:00
|
|
|
goto break_poll;
|
2020-08-16 02:54:44 +02:00
|
|
|
}
|
|
|
|
struct mp_subprocess_fd *fd = &opts->fds[n];
|
|
|
|
if (fd->on_read) {
|
2020-02-16 21:27:34 +01:00
|
|
|
char buf[4096];
|
|
|
|
ssize_t r = read(comm_pipe[n][0], buf, sizeof(buf));
|
|
|
|
if (r < 0 && errno == EINTR)
|
|
|
|
continue;
|
2020-08-16 02:54:44 +02:00
|
|
|
fd->on_read(fd->on_read_ctx, buf, MPMAX(r, 0));
|
2020-02-16 21:27:34 +01:00
|
|
|
if (r <= 0)
|
|
|
|
SAFE_CLOSE(comm_pipe[n][0]);
|
2020-08-16 02:54:44 +02:00
|
|
|
} else if (fd->on_write) {
|
|
|
|
if (!fd->write_buf->len) {
|
|
|
|
fd->on_write(fd->on_write_ctx);
|
|
|
|
if (!fd->write_buf->len) {
|
|
|
|
SAFE_CLOSE(comm_pipe[n][0]);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
ssize_t r = write(comm_pipe[n][0], fd->write_buf->start,
|
|
|
|
fd->write_buf->len);
|
|
|
|
if (r < 0 && errno == EINTR)
|
|
|
|
continue;
|
|
|
|
if (r < 0) {
|
|
|
|
// Let's not signal an error for now - caller can check
|
|
|
|
// whether all buffer was written.
|
|
|
|
SAFE_CLOSE(comm_pipe[n][0]);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
*fd->write_buf = bstr_cut(*fd->write_buf, r);
|
2020-02-16 21:27:34 +01:00
|
|
|
}
|
|
|
|
}
|
2014-11-22 07:21:33 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-02-10 19:16:16 +01:00
|
|
|
break_poll:
|
|
|
|
|
2014-11-22 07:21:33 +01:00
|
|
|
// Note: it can happen that a child process closes the pipe, but does not
|
|
|
|
// terminate yet. In this case, we would have to run waitpid() in
|
|
|
|
// a separate thread and use pthread_cancel(), or use other weird
|
2020-02-16 21:27:34 +01:00
|
|
|
// and laborious tricks in order to react to mp_cancel.
|
|
|
|
// So this isn't handled yet.
|
subprocess: implement proper detached processes on POSIX
The previous method for this sucked: for every launched detached
process, it started a thread, which then would leak if the launched
process didn't end before the player uninitialized. This was very racy
(although I bet the race condition wouldn't trigger in a 100 years), and
wasteful (threads aren't a cheap resource).
Implement it for POSIX directly. posix_spawn() has no direct support for
this, so we need to do it ourselves with fork(). We could probably do it
without fork(), and attempt to collect the PID in another thread. But
then we'd either have a waiting thread again, or we'd need to do an
unsafe waitpid(-1, ...) call. (POSIX process management sucks so badly,
how did they even manage this. Hopefully I'm just missing something, but
I'm not.) So now we depend on both posix_spawn() _and_ fork(), isn't it
fun?
Also call setsid(), to essentially detach the child process from the
terminal. (Otherwise it can receive various signals from the terminal,
which is probably not what you want.) posix_spawn() adds
POSIX_SPAWN_SETSID in newer POSIX releases, but we don't want to rely on
this yet.
The posix_spawnp() call is duplicated, but this is better than somehow
trying to unify the code paths.
Only somewhat tested, so enjoy the bugs.
2020-02-16 21:57:17 +01:00
|
|
|
if (pid)
|
|
|
|
while (waitpid(pid, &status, 0) < 0 && errno == EINTR) {}
|
2014-11-22 07:21:33 +01:00
|
|
|
|
|
|
|
done:
|
2020-02-16 21:27:34 +01:00
|
|
|
for (int n = 0; n < opts->num_fds; n++) {
|
|
|
|
SAFE_CLOSE(comm_pipe[n][0]);
|
|
|
|
SAFE_CLOSE(comm_pipe[n][1]);
|
|
|
|
}
|
2017-06-27 14:22:28 +02:00
|
|
|
SAFE_CLOSE(devnull);
|
2014-11-22 07:21:33 +01:00
|
|
|
|
subprocess: implement proper detached processes on POSIX
The previous method for this sucked: for every launched detached
process, it started a thread, which then would leak if the launched
process didn't end before the player uninitialized. This was very racy
(although I bet the race condition wouldn't trigger in a 100 years), and
wasteful (threads aren't a cheap resource).
Implement it for POSIX directly. posix_spawn() has no direct support for
this, so we need to do it ourselves with fork(). We could probably do it
without fork(), and attempt to collect the PID in another thread. But
then we'd either have a waiting thread again, or we'd need to do an
unsafe waitpid(-1, ...) call. (POSIX process management sucks so badly,
how did they even manage this. Hopefully I'm just missing something, but
I'm not.) So now we depend on both posix_spawn() _and_ fork(), isn't it
fun?
Also call setsid(), to essentially detach the child process from the
terminal. (Otherwise it can receive various signals from the terminal,
which is probably not what you want.) posix_spawn() adds
POSIX_SPAWN_SETSID in newer POSIX releases, but we don't want to rely on
this yet.
The posix_spawnp() call is duplicated, but this is better than somehow
trying to unify the code paths.
Only somewhat tested, so enjoy the bugs.
2020-02-16 21:57:17 +01:00
|
|
|
if (!spawned || (pid && WIFEXITED(status) && WEXITSTATUS(status) == 127)) {
|
2020-02-16 21:27:34 +01:00
|
|
|
res->error = MP_SUBPROCESS_EINIT;
|
subprocess: implement proper detached processes on POSIX
The previous method for this sucked: for every launched detached
process, it started a thread, which then would leak if the launched
process didn't end before the player uninitialized. This was very racy
(although I bet the race condition wouldn't trigger in a 100 years), and
wasteful (threads aren't a cheap resource).
Implement it for POSIX directly. posix_spawn() has no direct support for
this, so we need to do it ourselves with fork(). We could probably do it
without fork(), and attempt to collect the PID in another thread. But
then we'd either have a waiting thread again, or we'd need to do an
unsafe waitpid(-1, ...) call. (POSIX process management sucks so badly,
how did they even manage this. Hopefully I'm just missing something, but
I'm not.) So now we depend on both posix_spawn() _and_ fork(), isn't it
fun?
Also call setsid(), to essentially detach the child process from the
terminal. (Otherwise it can receive various signals from the terminal,
which is probably not what you want.) posix_spawn() adds
POSIX_SPAWN_SETSID in newer POSIX releases, but we don't want to rely on
this yet.
The posix_spawnp() call is duplicated, but this is better than somehow
trying to unify the code paths.
Only somewhat tested, so enjoy the bugs.
2020-02-16 21:57:17 +01:00
|
|
|
} else if (pid && WIFEXITED(status)) {
|
2020-02-16 21:27:34 +01:00
|
|
|
res->exit_status = WEXITSTATUS(status);
|
subprocess: implement proper detached processes on POSIX
The previous method for this sucked: for every launched detached
process, it started a thread, which then would leak if the launched
process didn't end before the player uninitialized. This was very racy
(although I bet the race condition wouldn't trigger in a 100 years), and
wasteful (threads aren't a cheap resource).
Implement it for POSIX directly. posix_spawn() has no direct support for
this, so we need to do it ourselves with fork(). We could probably do it
without fork(), and attempt to collect the PID in another thread. But
then we'd either have a waiting thread again, or we'd need to do an
unsafe waitpid(-1, ...) call. (POSIX process management sucks so badly,
how did they even manage this. Hopefully I'm just missing something, but
I'm not.) So now we depend on both posix_spawn() _and_ fork(), isn't it
fun?
Also call setsid(), to essentially detach the child process from the
terminal. (Otherwise it can receive various signals from the terminal,
which is probably not what you want.) posix_spawn() adds
POSIX_SPAWN_SETSID in newer POSIX releases, but we don't want to rely on
this yet.
The posix_spawnp() call is duplicated, but this is better than somehow
trying to unify the code paths.
Only somewhat tested, so enjoy the bugs.
2020-02-16 21:57:17 +01:00
|
|
|
} else if (spawned && opts->detach) {
|
|
|
|
// ok
|
2020-02-16 21:27:34 +01:00
|
|
|
} else if (killed_by_us) {
|
|
|
|
res->error = MP_SUBPROCESS_EKILLED_BY_US;
|
2014-11-22 07:21:33 +01:00
|
|
|
} else {
|
2020-02-16 21:27:34 +01:00
|
|
|
res->error = MP_SUBPROCESS_EGENERIC;
|
2014-11-22 07:21:33 +01:00
|
|
|
}
|
|
|
|
}
|