From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <44a20375d50e77dfb05d75c5ab989474@brasstown.quanstro.net> References: <16d20c29be00a62eacb3dba96a700922@brasstown.quanstro.net> <44a20375d50e77dfb05d75c5ab989474@brasstown.quanstro.net> Date: Wed, 25 Apr 2012 16:14:40 -0400 Message-ID: Subject: Re: [9fans] what am i missing From: Russ Cox To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Topicbox-Message-UUID: 7f106c24-ead7-11e9-9d60-3106f5b1d025 On Wed, Apr 25, 2012 at 4:06 PM, erik quanstrom wro= te: > good point. =C2=A0procrfork() does nowait. =C2=A0but then how do i get > a wait message. =C2=A0i'm really hoping the answer is not "you don't". I don't believe you have looked at the context here. This is only used by procexec, which is trying to simulate an exec replacing a proc. It does that by setting p->needexec=3D1 and jumping back into the scheduler. The scheduler will call _schedexec, which does an rfork of its own (not procrfork), the "exec"ed program runs in the child, and the parent waits for the wait message saying the child is done. An unexpected wait message shold not come in, but if one does, might as well be tidy and free it before continuing the loop. This is not Linux. Each individual proc (thread) has its own set of children, so the only wait message that should arrive on that proc is the one it expects. Other procexecs running in other procs will not affect it. Russ