Date: Tue, 4 Nov 1997 02:10:31 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Stephen McKay <syssgm@dtir.qld.gov.au>, Terry Lambert <tlambert@primenet.com> Cc: freebsd-hackers@FreeBSD.ORG, gurney_j@resnet.uoregon.edu Subject: Re: portal pid not correct... Message-ID: <199711041010.CAA11903@salsa.gv.tsc.tdk.com> In-Reply-To: Stephen McKay <syssgm@dtir.qld.gov.au> "Re: portal pid not correct..." (Nov 4, 2:31pm)
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711041010.CAA11903>