Emulate POSIX_SPAWN_CLOEXEC_DEFAULT in fork/exec #79

iCharlesHu · 2025-06-13T22:57:30Z

POSIX_SPAWN_CLOEXEC_DEFAULT is only available on Darwin. Emulate POSIX_SPAWN_CLOEXEC_DEFAULT on other platforms by calling close after fork, before exec.

This commit also removes _subprocess_posix_spawn_fallback because we can't emulate POSIX_SPAWN_CLOEXEC_DEFAULT in a thread-safe manner while using posix_spawn.

Resolves: #46

Sources/_SubprocessCShims/process_shims.c

jakepetroules · 2025-06-13T23:16:51Z

Sources/_SubprocessCShims/process_shims.c

+        hi = getdtablesize();
+    }
+#else
+    int hi = 1024;


Where does '1024' come from and how safe is it to default to this vs making this #error and requiring a specific implementation for new platforms?

Also, the following additional platforms support getdtablesize: FreeBSD, OpenBSD, NetBSD, Solaris, QNX.

Instead of #error, how about if I just call getdtablesize unconditionally here and have it naturally error on platforms that don't support it.

lin72h · 2025-06-14T21:50:45Z

FreeBSD PR #1698 adds support for POSIX O_CLOFORK, which could simplify this implementation.

iCharlesHu · 2025-06-16T17:55:52Z

FreeBSD PR #1698 adds support for POSIX O_CLOFORK, which could simplify this implementation.

Ahh thanks. Good to know.

parkera · 2025-06-26T23:36:06Z

Sources/_SubprocessCShims/process_shims.c

-    char * _Nullable const args[_Nonnull],
-    char * _Nullable const env[_Nullable],
-    gid_t * _Nullable process_group_id
+int _shims_snprintf(


Why do we need this shim?

On Linux this function isn't exposed via import Glibc

parkera · 2025-06-26T23:36:33Z

Sources/_SubprocessCShims/process_shims.c

+    struct dirent *dir_entry = NULL;
+    while ((dir_entry = readdir(dir_ptr)) != NULL) {
+        char *entry_name = dir_entry->d_name;
+        int number = _positive_int_parse(entry_name);


Is this really the right way to do this? Seems very ad-hoc.

Yes. So there are generally two ways to determine the highest fd number on Linux:

Use getrlimit

Read /proc/self/fd
The difference between the two is that 1) only tells you the limit whereas 2) tells you the actual highest fd opened. I decided to go for 2) because it's more accurate. Also since this code is executed between fork() and exec(), there is no threading issues here.

(and racy)

It's not racy because you're in a new process with just one thread. It's not ideal because it uses malloc and in theory the malloc lock might be in a bad state because it's after fork

And yes, the problem with the limit is that the limit is often VERY high (i.e. 1M) which means you need to issue A LOT of closes

@iCharlesHu I implemented a version of this in AsyncProcess which should be (v)fork safe because it doesn't allocate: https://github.com/swiftlang/swift-sdk-generator/blob/3f4a6a800414010da0057985f80b2aba5dd4fc60/Sources/CProcessSpawnSync/internal-helpers.h#L57-L98

(glibc (LGPL!) also has an implementation: https://github.com/bminor/glibc/blob/6afece738c2b8408585272a95090ce5d5345dd19/sysdeps/unix/sysv/linux/closefrom_fallback.c#L31)

Sources/_SubprocessCShims/process_shims.c

Tests/SubprocessTests/SubprocessTests+Unix.swift

POSIX_SPAWN_CLOEXEC_DEFAULT is only available on Darwin. Emulate POSIX_SPAWN_CLOEXEC_DEFAULT on other platforms by calling close after fork, before exec. This commit also removes _subprocess_posix_spawn_fallback because we can't emulate POSIX_SPAWN_CLOEXEC_DEFAULT in a thread-safe manner while using posix_spawn.

iCharlesHu · 2025-07-03T04:40:32Z

Addressed review comments.

jakepetroules · 2025-07-03T17:38:57Z

Sources/_SubprocessCShims/process_shims.c

-    //  - Solaris 11.4 (August 2018)
-    //  - NetBSD 10.0 (March 2024)
-    return posix_spawn_file_actions_addchdir(file_actions, path);
+#  define _SUBPROCESS_SIG_MAX 32


POSIX 2024 added NSIG_MAX:

{NSIG_MAX}
Some historical implementations provided compile-time constants NSIG or SIGMAX to define the maximum number of signals the implementation supported, but these values did not necessarily reflect the number of signals that could be handled using a sigset_t. With the addition of real-time signals and the desire by some applications to be able to allocate additional real-time signals at run-time, neither of these constants provided a useable, portable value. {NSIG_MAX} was added to the standard to allow applications to determine the maximum number of signals that an implementation will support based on the size of the sigset_t type (defined in <signal.h>).

32 for Darwin, 64 for Linux, 128 for FreeBSD.

Here is what Ruby's vm_core.h does, I suggest we replicate that for maximum portability:

#if defined(NSIG_MAX) /* POSIX issue 8 */ # undef NSIG # define NSIG NSIG_MAX #elif defined(_SIG_MAXSIG) /* FreeBSD */ # undef NSIG # define NSIG _SIG_MAXSIG #elif defined(_SIGMAX) /* QNX */ # define NSIG (_SIGMAX + 1) #elif defined(NSIG) /* 99% of everything else */ # /* take it */ #else /* Last resort */ # define NSIG (sizeof(sigset_t) * CHAR_BIT + 1) #endif

https://github.com/ruby/ruby/blob/c584cc079eef2f4e314a97eff310c9947e1d7010/vm_core.h#L144-L156

jakepetroules · 2025-07-03T18:03:38Z

Sources/_SubprocessCShims/process_shims.c

+        hi = getdtablesize();
+    }
+#else
+    int hi = getdtablesize();


Linux man page recommends that portable applications call sysconf(_SC_OPEN_MAX) instead (which is defined by POSIX).

jakepetroules · 2025-07-03T18:04:15Z

Sources/_SubprocessCShims/process_shims.c

-        flags |= POSIX_SPAWN_SETPGROUP;
-        rc = posix_spawnattr_setpgroup(&spawn_attr, *process_group_id);
-        if (rc != 0) { return rc; }
+static int _highest_possibly_open_fd(void) {


Why make this platform-conditional? On Linux, /dev/fd exists as symlinks, is there any reason not to always use /dev/fd? That should work on pretty much all platforms.

jakepetroules · 2025-07-03T18:13:54Z

Tests/SubprocessTests/SubprocessTests+Unix.swift

+            output: .string,
+            error: .string
+        )
+        close(pipe.writeEnd.rawValue)


This will end up closing writeEnd twice because of the close in the defer block above, which looks unsafe. And I can't see how that behavior is relevant to the test. Instead use the closeAfter API from FileDescriptor. It doesn't provide an async overload but here's a polyfill I wrote:

extension FileDescriptor { /// Runs a closure and then closes the FileDescriptor, even if an error occurs. /// /// - Parameter body: The closure to run. /// If the closure throws an error, /// this method closes the file descriptor before it rethrows that error. /// /// - Returns: The value returned by the closure. /// /// If `body` throws an error /// or an error occurs while closing the file descriptor, /// this method rethrows that error. public func closeAfter<R>(_ body: () async throws -> R) async throws -> R { // No underscore helper, since the closure's throw isn't necessarily typed. let result: R do { result = try await body() } catch { _ = try? self.close() // Squash close error and throw closure's throw error } try self.close() return result } }

lin72h · 2025-07-07T03:27:45Z

Just a heads up - the PR has merged. I think the timing means it'll likely make it into the upcoming FreeBSD 15 release in December.

itingliu

The Linux CI failure looks relevant

[7/22] Compiling CSystem shims.c
/__w/swift-subprocess/swift-subprocess/Sources/_SubprocessCShims/process_shims.c:318:28: error: use of undeclared identifier 'val'
  318 |     if (errno == ERANGE || val <= 0 || val > INT_MAX) {
      |

itingliu · 2025-07-07T18:16:29Z

Sources/_SubprocessCShims/process_shims.c

-            &file_actions, file_descriptors[2], STDOUT_FILENO
-        );
-        if (rc != 0) { return rc; }
+    if (errno == ERANGE || val <= 0 || val > INT_MAX) {


I think this is what's causing the Linux CI failure

[7/22] Compiling CSystem shims.c /__w/swift-subprocess/swift-subprocess/Sources/_SubprocessCShims/process_shims.c:318:28: error: use of undeclared identifier 'val' 318 | if (errno == ERANGE || val <= 0 || val > INT_MAX) {

Should be value instead?

iCharlesHu requested review from parkera and itingliu June 13, 2025 22:57

iCharlesHu force-pushed the charles/fork-exec-close-fd branch from 6e9afb5 to 3e47e05 Compare June 13, 2025 23:01

jakepetroules reviewed Jun 13, 2025

View reviewed changes

Sources/_SubprocessCShims/process_shims.c Outdated Show resolved Hide resolved

iCharlesHu force-pushed the charles/fork-exec-close-fd branch from 3e47e05 to 2d9a937 Compare June 13, 2025 23:11

jakepetroules reviewed Jun 13, 2025

View reviewed changes

ricardobranco777 mentioned this pull request Jun 15, 2025

Add support for POSIX O_CLOFORK freebsd/freebsd-src#1698

Closed

7 tasks

iCharlesHu force-pushed the charles/fork-exec-close-fd branch from 2d9a937 to cd79141 Compare June 16, 2025 18:24

iCharlesHu requested a review from cthielen June 17, 2025 22:05

This was referenced Jun 20, 2025

Add support for POSIX O_CLOFORK DragonFlyBSD/DragonFlyBSD#28

Open

Add support for POSIX O_CLOFORK openbsd/src#46

Closed

Add support for POSIX O_CLOFORK NetBSD/src#53

Open

parkera reviewed Jun 26, 2025

View reviewed changes

cthielen reviewed Jun 26, 2025

View reviewed changes

Sources/_SubprocessCShims/process_shims.c Outdated Show resolved Hide resolved

Sources/_SubprocessCShims/process_shims.c Show resolved Hide resolved

Tests/SubprocessTests/SubprocessTests+Unix.swift Outdated Show resolved Hide resolved

iCharlesHu force-pushed the charles/fork-exec-close-fd branch from cd79141 to c217b39 Compare July 3, 2025 04:40

jakepetroules requested changes Jul 3, 2025

View reviewed changes

jakepetroules mentioned this pull request Jul 4, 2025

[OpenBSD] Subprocess+Linux.swift does not build here #115

Open

itingliu reviewed Jul 7, 2025

View reviewed changes

Emulate POSIX_SPAWN_CLOEXEC_DEFAULT in fork/exec #79

Are you sure you want to change the base?

Emulate POSIX_SPAWN_CLOEXEC_DEFAULT in fork/exec #79

Conversation

iCharlesHu commented Jun 13, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lin72h commented Jun 14, 2025

Uh oh!

iCharlesHu commented Jun 16, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

iCharlesHu commented Jul 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lin72h commented Jul 7, 2025

Uh oh!

itingliu left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!