Re: kern/49017: vfork does not suspend all threads

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 6 Apr 2017 07:16:36 -0400
    From:        christos%zoulas.com@localhost (Christos Zoulas)
    Message-ID:  <20170406111636.92DF217FDA8%rebar.astron.com@localhost>

  | It is much more restricted than that. For example if the child
  | continues and returns from its current stack frame to other higher
  | up frames, it makes changes to them so when the parent resumes it
  | finds an inconsistent state.

Just the same as setjmp() ... no question but that there are restrictions
after a vfork(), but they're not as strict (not nearly as strict) as async
signal safe (which needs to be prepared to execute with the "parent" in
any state at all - here we know the parent is blocked in vfork() so is
not currently doing anything.)

  | |  would be a "complete the fork" sys call, which would turn the
  | |  vfork() into a fork()

  | The difficulty with that is that the child needs to know that it has been
  | vforked instead of forked... So the child needs code to handle both cases
  | in general which is annoying.

Huh?   The code is

	if (vfork() == 0) {
		/* here I am the child */
	}

How does the child possibly not know it has been vforked?   What I
suggested (as some kind of dream, not a serious proposal, or not without
trying it anyway) would be to allow

	if (vfork() == 0) {
		/* child, with parent blocked and shared mem */
		
		/* code here, probably tests to decide what next */

		vfork_into_fork();
		/* now parent is unblocked, and child has its own addr space */
	}

(and no, I don't think "vfork_into_fork()" is a sensible name...)


Joerg Sonnenberger <joerg%bec.de@localhost> said:
  | The problem is that many of the functions outside the "async signal safe"
  | category are exactly allowed to such things.

Sure, but there are plenty that are, much more than what is safe in a
signal handler.

There's no question but that using vfork() requires some care (or very
simple operations) but that's not a reason to restrict it more than what
it already is.

For the PR that started all this, my suggestion would be to simply fix the
man page, and close it.

kre