Making a request inside an endpoint handler cause error

[dephiros]

Hi,
I am trying to make a network request using the built-in std.http.Client but run into this error:

objc[53343]: +[NSString initialize] may have been in progress in another thread when fork() was called.
objc[53343]: +[NSString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.

The code is something like:

fn onPost(endpoint: *zap.SimpleEndpoint, request: zap.SimpleRequest) void {
    std.debug.print("\nSTART ONPOST\n", .{});
    const self = @fieldParentPtr(Self, "endpoint", endpoint);
    const url = "https://jsonplaceholder.typicode.com/todos/1";
    var client = std.http.Client{ .allocator = allocator };
    defer client.deinit();
    return client.fetch(allocator, .{
        .location = .{ .url = url },
    });
}

Sounds like an error related to calling fork inside a thread? I don't have a lot of context with low-level programing so any help/suggestions are appreciated

[renerocksai]

Zig version, zap version please. I assume this is macOS. What architecture? (X86/arm)

I guess std.http is the culprit here.

In zap's CI tests (zig 0.11) , I had to comment out a defer request.deinit or else it would panic.

So maybe try that?

[dephiros]

zig : 0.12.0-dev.1718+3acb0e30a
zap: 0.12.0 branch
Arch: aarch64
OS: Mac (M1)

Thanks for the suggestion @renerocksai , I will try that and report back

[dephiros]

@renerocksai
It is indeed related to std.Client since commenting out the client code and things work as normal

TDLR(as far as my limited knowledge on these area):

• zap use threads
• zap forks a process
• std.Client calls into Foundation lib - probably making network call?
• This triggers the safety check that Apple built into High Sierra and later

To test the thread theory, I set zap.start(.{ .threads = 1, .workers = 1 }); and the issue also disappear.
Interestingly, zap.start(.{ .threads = 2, .workers = 1 }); causes segfault and zap.start(.{ .threads = 1, .workers = 2 }); causes segfault. So I guessing the fork comes from worker
Not quite sure where std.Client calls into Apple ObjC lib though 🤷

Rabbit Hole

Looking into that objc error, there are quite a few answer from python and ruby community(ex1, ex2, ex3, this one in particular talks about multithreading module in python. They all seems to point to the same issues around fork inside a thread:
https://sealiesoftware.com/blog/archive/2017/6/5/Objective-C_and_fork_in_macOS_1013.html

+initialize methods still have restrictions around fork(). The problem is that the thread-safety guarantees of +initialize implicitly introduce locks around state that the Objective-C runtime does not control. There is no good way to make +initialize both thread-safe and fork-safe. Instead the Objective-C runtime simply halts the process instead of running any +initialize override in the child process

https://blog.phusion.nl/2017/10/13/why-ruby-app-servers-break-on-macos-high-sierra-and-what-can-be-done-about-it/

In High Sierra, Apple has defined some rules on what is allowed and not allowed after forking, and they have also added async-signal-safety to a limited number of APIs. They have also started enforcing rules.

https://blog.phusion.nl/2017/10/13/why-ruby-app-servers-break-on-macos-high-sierra-and-what-can-be-done-about-it/

One of the rules that Apple defined is that you may not call Foundation class initializers after forking. This function crashes the process immediately.