View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007943||GNUnet||util library||public||2023-09-25 14:24||2023-11-27 13:27|
|Reporter||schanzen||Assigned To||Christian Grothoff|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Summary||0007943: vfork deprecated|
|Description||../src/util/os_priority.c:439:9: warning: 'vfork' is deprecated: Use posix_spawn or fork [-Wdeprecated-declarations]|
ret = vfork ();
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/unistd.h:604:1: note: 'vfork' has been explicitly marked deprecated here
__deprecated_msg("Use posix_spawn or fork")
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:215:48: note: expanded from macro '__deprecated_msg'
#define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))
1 warning generated.
Can we just use fork() and accept the issue or what do we do?
|Tags||No tags attached.|
I don't care about vfork() being deprecated. It is precisely what we need here. Without it, you will see very hard to diagnose problems with processes not terminating / hanging, I really would not touch this part. It works, it is correct, and fork is incorrect. Some idiots deprecating vfork() doesn't change that.
well. we should care when it is removed, which is what this indicates.
Considering that this is an ifdef for portability _right now_ in order to preserve portability, we need a plan b.
||No, deprecation doesn't necessarily indicate impending removal for a syscall. It could take a decade or more, as doing so breaks legacy applications. Let's do the plan B when they *actually* remove it. And: my original post does spell out a complex plan B with pipes, just that is horribly inefficient by comparison.|
Again let me reiterate: vfork() is used _only_ for macos/darwin. Linux already uses fork() only.
From fork(2) in macos:
The vfork system call can be used to create new processes. As of macOS 12.0, this system call behaves identically to the fork(2) system call, except without calling
any handlers registered with pthread_atfork(2).
This system call is deprecated. In a future release, it may begin to return errors in all cases, or may be removed entirely. It is extremely strongly recommended to
replace all uses with fork(2) or, ideally, posix_spawn(3).
also from fork(2) in linux:
The requirements put on vfork() by the standards are weaker than
those put on fork(2), so an implementation where the two are
synonymous is compliant. In particular, the programmer cannot
rely on the parent remaining blocked until the child either
terminates or calls execve(2), and cannot rely on any specific
behavior with respect to shared memory.
So for linux, it does not really make sense to rely on the behaviour you want according to the manpage. For macos, the same it true but they actually mark the call deprecated in the code. Which does not mean, that it is not deprecated for linux as well.
|2023-09-25 14:24||schanzen||New Issue|
|2023-09-25 14:24||schanzen||Status||new => assigned|
|2023-09-25 14:24||schanzen||Assigned To||=> Christian Grothoff|
|2023-09-25 14:26||schanzen||Target Version||=> 0.21.0|
|2023-09-25 14:34||Christian Grothoff||Note Added: 0020547|
|2023-09-25 14:36||Christian Grothoff||Note Edited: 0020547|
|2023-09-25 20:46||schanzen||Note Added: 0020554|
|2023-09-25 20:50||Christian Grothoff||Note Added: 0020555|
|2023-10-06 11:37||schanzen||Note Added: 0020568|
|2023-11-27 13:27||schanzen||Target Version||0.21.0 => 1.0.0|