Re: kern/38670: ^Z does not work anymore for this program.

[christos%zoulas.com@localhost (Christos Zoulas)]

The following reply was made to PR kern/38670; it has been noted by GNATS.

From: christos%zoulas.com@localhost (Christos Zoulas)
To: David Holland <dholland-bugs%netbsd.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost, 
        gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/38670: ^Z does not work anymore for this program.
Date: Sun, 22 Feb 2009 11:09:38 -0500

 On Feb 22, 10:01am, dholland-bugs%netbsd.org@localhost (David Holland) wrote:
 -- Subject: Re: kern/38670: ^Z does not work anymore for this program.
 
 | Changing that call to cv_wait_sig() ought to restore the previous
 | behavior; however, it's not clear that this is a particularly good
 | idea, because if a signal arrives and results in ERESTARTSYS there'll
 | be another child process created, and if it results in EINTR then the
 | parent and the child will both be running on the same stack in the
 | same address space, and demons will fly out of someone's nose.
 | 
 | However, since having arbitrarily long uninterruptible waits isn't
 | such a great idea, maybe we should try to come up with a way to make
 | this work. Or maybe an adequate substitute is to change the WCHAN to
 | "vfork" so one can at least tell what's happening and find/kill off
 | the child process if things are stuck. But this probably would
 | probably require breaking the CV abstraction.
 | 
 | Also, I wonder what happens if someone does ptrace(PT_ATTACH, ...) on
 | a vfork child. This should probably be forbidden; it currently isn't
 | and I suspect it will make a mess.
 
 Thanks for the explanation. I guess we should leave this open until we
 fix at least the ptrace case.
 
 christos