Re: [REQUEST FOR VOTES] snmpd: Call fclose() after fdopen() but not close()

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.