On 2020-08-15 07:14, Magnus Fromreide wrote: > 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.
On https://www.eetimes.com/how-uclinux-provides-mmu-less-processors-with-an-alternative/# I found the following, which confirms the above: uClinux implements vfork() in order to compensate for the lack of fork(). When a parent process calls vfork() to create a child, both processes share all their memory space including the stack. vfork() then suspends the parent's execution until the child process either calls exit() or execve(). > 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. How about removing the pass_persist for uClinux and restoring it if a user asks to restore that support? uClinux was created in 1998, when the price difference between microprocessors with or without MMU was much larger than today. Today a Raspberry Pi is available for $35. That product includes not only a CPU with MMU but also a board and connectors. Bart. _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
