Re: waitpid() with WUNTRACED flag? (was Re: Hang on ctrl+Z after the MPSAFE tsleep/wakeup commit)

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Ok, the code doesn't really reflect my question here; on computers here
:running other OSes, including DragonFly 1.2.x-RELEASE, waitpid() (or wait4)
:doesn't return after ^Z+`fg' even with WUNTRACED (I can confirm this by the
:fact that warnx() doesn't print "WSTOPSIG(%d) = %d\n" message), thus no such
:problem exists.  I don't know if it's an (POSIX-ly or SUS-ly?) expected
:behavior, but are we going to change that?

    I don't know what the expected behavior is, but the only reason the
    parent isn't seeing the STOP signal on the child in FreeBSD is due to
    a fluke in the way the parent's own STOP signal is handled, which is
    causing the parent to stop before it's wait*() scans the list of
    child processes.  If you were to wake up the parent on FreeBSD with a
    kill -CONT from another shell, it will see the vi's stop signal.

    When you 'fg' the process group, both parent and child are being
    restarted at the same time.  The parent then starts its scan of the list
    of child processes and of course no longer sees the child in a stopped
    state, so it only reports the SIGCONT, instead of a SIGSTOP followed by
    a SIGCONT.  (The stop/cont state is held in a single variable in the
    proc structure so multiple stops and conts are not queued to the parent's
    wait*()).

    DragonFly is currently scanning the list of child processes *BEFORE* it
    stops, so it sees the stopped child and tries to return its status,
    but then the parent process stops before it returns to user mode.
    When you 'fg' the process group, DragonFly proceeds to return the
    original STOP status that it has already processed (so it doesn't get
    overwritten by the new CONT status), then the parent program loops on
    the waitpid() and DragonFly sees the CONT status.

    Which is more correct?  I don't know.  I think the userland program
    itself (the parent, as in your test program and in vipw) might be
    incorrect.

						-Matt