On Fri, Aug 14, 2020 at 07:38:09PM -0700, Bart Van Assche wrote: > On 2020-08-14 17:05, Magnus Fromreide wrote: > > The vfork child only blocks the parent until it have performed an successful > > exec so that part looks ok [ ... ] > > Hi Magnus, > > Are you sure of this? From the Linux vfork() man page > (https://man7.org/linux/man-pages/man2/vfork.2.html): > > 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.
This allows vfork to not block the parent until the child has called _exit or exec*, it does not allow the child to block the parent until completion. Please note that in our case this is arch-specific code for uClinux where the fork() system call doesn't exist so I think we can be assured that vfork will block the parent there. If we had been religous about marking all internal fd's as CLOEXEC then pass_perrsistant could be rewritten using posix_spawn which sounds a lot better but we are sadly lacking in the CLOEXEC department. To be honest the calls to perror and exit if exec fails is more suspicious as that is explicitly stated to cause undefined behaviour. With all this I should probably repeat that I am in favour of dropping the pass_persist support for uClinux. /MF _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
