From owner-freebsd-hackers Tue Nov 4 02:12:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA00853 for hackers-outgoing; Tue, 4 Nov 1997 02:12:07 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA00842 for ; Tue, 4 Nov 1997 02:12:02 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id CAA21023; Tue, 4 Nov 1997 02:10:37 -0800 (PST) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id CAA03240; Tue, 4 Nov 1997 02:10:36 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id CAA11903; Tue, 4 Nov 1997 02:10:31 -0800 (PST) From: Don Lewis Message-Id: <199711041010.CAA11903@salsa.gv.tsc.tdk.com> Date: Tue, 4 Nov 1997 02:10:31 -0800 In-Reply-To: Stephen McKay "Re: portal pid not correct..." (Nov 4, 2:31pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Stephen McKay , Terry Lambert Subject: Re: portal pid not correct... Cc: freebsd-hackers@FreeBSD.ORG, gurney_j@resnet.uoregon.edu Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Nov 4, 2:31pm, Stephen McKay wrote: } Subject: Re: portal pid not correct... } To reliably coordinate with your child process use a pipe. A single byte } sent through the pipe could be your "go" signal. If you want more, then } pick several different byte values to represent different actions to take. } If the pipe closes unexpectedly, you know that the other party died horribly. } And one of your byte codes could indicate an error and be followed by the } errno and/or an error message. I've used this trick before. If you don't need to send a message other than "go", you can just close the write end of the pipe, and the process at the read end of the pipe knows that it's time to proceed when it sees the EOF. This was safe in the situation where I used it. In my case I wanted a child process to wait for its parent to close the socket created by accept() before writing data to the socket. If the child didn't wait, it would be possible for child to write its data and exit before the parent closed the socket. This could cause the parent to hang in close() until the network buffers drained. --- Truck