Rethinking the interface for `fork`

[kamalmarhubi]

I was writing a shell as an example for nix, and I realised that #555 makes a really good point: the code that runs in the child after fork(2) must not allocate if there is more than one thread. I don't know if fork should necessarily be made unsafe, but certainly we need to document better what is ok to do afterwards.

This is somewhat related to #90 in that there's an execution context where only limited operations should be performed. Ideally nix would force only correct usage, but at the same time there's a lot of value of staying close to the libc definitions of functions. (#190 seems connected here too.)

[jonas-schievink]

Also see http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them

And the man page says:

After a fork() in a multithreaded program, the child can safely
call only async-signal-safe functions (see signal-safety(7)) until
such time as it calls execve(2).

This makes it sound like fork really really should be made unsafe: Spawning threads and calling non-signal-safe function is possible in safe Rust, therefore there must not be a safe way to do so after a fork. Instead, nix could provide safe utility functions that do common patterns like fork + execve in a safe way.

[jonas-schievink]

This has come up in the standard library, too: rust-lang/rust#39575

[asomers]

You're right that fork is unsafe. But is it unsafe in the Rust sense? I think we should follow whatever decision rust-lang makes in the issue you linked.

[Susurrus]

@asomers I read through some of the discussion there. The argument is that UB should be assumed to include memory unsafety by default. Specifically for fork() there are some more reasonings that should make this more likely.

[asomers]

Is there any undefined behavior associated with calling async-signal-unsafe functions after forking? I can't find any. fork(2) doesn't mention any undefined behavior. Instead, it suggests not calling async-signal-unsafe functions in order to prevent deadlocks and the like.

[Susurrus]

@jonas-schievink @asomers Did this get cleaned resolved with the merging of #695?

[jonas-schievink]

I believe the conclusion was that fork is safe but (eg.) allocating afterwards can cause deadlocks, which is still a footgun.

I don't know if a deadlock will always be the worst that can happen. Also, deadlocks will only happen when forking while another thread is allocating memory (or holding another lock), making this an annoying-to-debug race.

To further the issue, std lib functions generally don't document if they allocate or which libc functions they call.

If you don't think it makes sense to provide a safer interface that prevents this, you can probably close this issue.

[jonas-schievink]

Update: The conclusion of rust-lang/rust#39575 was that before_exec should have been an unsafe function, and has been deprecated and replaced by an unsafe fn pre_exec. Thus fork should also be considered an unsafe operation.

[kamalmarhubi]

@jonas-schievink thanks for that update!

[interacsion]

The rustdocs for fork and forkpty forget to mention the restriction is lifted after execve is called, I think this is mildly confusing