One problem may be that fork() kills background threads, so now any program that uses libcurl + fork has to have a new API to restart the DNS thread (or use posix_atfork which is a big PITA), and that might break existing programs using curl.

▲

ComputerGuru 3 days ago | parent | next [-]

It’s not too much of an exaggeration to say that everything about using fork() instead of vfork() plus exec() is essentially fundamentally broken in modern osdev without a whole stack of hacks to try and patch individual issues one-by-one.

	▲	EPWN3D 3 days ago \| parent [-]
		It's not an exaggeration in any sense. fork(2) basically cannot be done correctly in modern userspace stacks.

▲

loeg 3 days ago | parent | prev [-]

A surmountable problem, sure.

▲

rwmj 3 days ago | parent [-]

Sometimes. To give one counterexample, golang doesn't have a way to restart the threads it uses for I/O (apparently a decision the golang developers made), so if you're embedding golang code in another binary, it better not call fork. (The reason for this warning: https://gitlab.com/nbdkit/nbdkit/-/commit/2589e6da40939af9ae...)

	▲	loeg 3 days ago \| parent [-]
		This is a policy choice of Golang, but a C library like Curl (the topic of this thread) is not constrained by the policy choices of the Go developers. Curl could use MADV_WIPEONFORK or other primitives to restart its DNS thread automatically.