From owner-freebsd-hackers Mon Nov 3 20:31:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA08073 for hackers-outgoing; Mon, 3 Nov 1997 20:31:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ren.dtir.qld.gov.au (firewall-user@ns.dtir.qld.gov.au [203.108.138.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA08067 for ; Mon, 3 Nov 1997 20:31:49 -0800 (PST) (envelope-from syssgm@dtir.qld.gov.au) Received: by ren.dtir.qld.gov.au; id OAA13864; Tue, 4 Nov 1997 14:47:06 +1000 (EST) Received: from ogre.dtir.qld.gov.au(167.123.8.3) by ren.dtir.qld.gov.au via smap (3.2) id xma013859; Tue, 4 Nov 97 14:46:55 +1000 Received: from localhost.dtir.qld.gov.au (localhost.dtir.qld.gov.au [127.0.0.1]) by ogre.dtir.qld.gov.au (8.8.7/8.8.7) with SMTP id OAA27497; Tue, 4 Nov 1997 14:31:32 +1000 (EST) Message-Id: <199711040431.OAA27497@ogre.dtir.qld.gov.au> X-Authentication-Warning: ogre.dtir.qld.gov.au: localhost.dtir.qld.gov.au [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: freebsd-hackers@freebsd.org, gurney_j@resnet.uoregon.edu, syssgm@dtir.qld.gov.au Subject: Re: portal pid not correct... References: <199711040212.TAA14153@usr09.primenet.com> In-Reply-To: <199711040212.TAA14153@usr09.primenet.com> from Terry Lambert at "Tue, 04 Nov 1997 02:12:36 +0000" Date: Tue, 04 Nov 1997 14:31:31 +1000 From: Stephen McKay Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tuesday, 4th November 1997, Terry Lambert wrote: >> I took a look at the code.. and basicly it doesn't become a daemon before >> tring to mount the fs... and this is understandable else you can't return >> a failed mount... >> >> now as I see this, there are a couple ways to fix this... >> a) just become a daemon and then mount, this isn't very attrative >> as the error doesn't get reported >> b) do something were it will fork off the child, child will >> immediately SIGSTOP itself, then parent will mount, and then >> parent will SIGCONT the process for normal execution, or kill >> it off if the mount failed. >> c) insert your idea hear > >Use vfork for the side effect before child exit/exec. Man vfork for >details. Yuck! vfork() sucks big time. Forget it exists and you will do well. 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. You can use this method for coordinating either way (the parent waiting until the child has got something done, or the other way around) so it is better than vfork() anyway and it is portable back to (at least) Edition 7. Stephen.