From owner-freebsd-chat Sat Dec 29 21:41:17 2001 Delivered-To: freebsd-chat@freebsd.org Received: from catalyst.sasknow.net (catalyst.sasknow.net [207.195.92.130]) by hub.freebsd.org (Postfix) with ESMTP id 5900537B416 for ; Sat, 29 Dec 2001 21:41:14 -0800 (PST) Received: from localhost (ryan@localhost) by catalyst.sasknow.net (8.11.6/8.11.6) with ESMTP id fBU5f3p47742; Sat, 29 Dec 2001 23:41:03 -0600 (CST) (envelope-from ryan@sasknow.com) X-Authentication-Warning: catalyst.sasknow.net: ryan owned process doing -bs Date: Sat, 29 Dec 2001 23:41:03 -0600 (CST) From: Ryan Thompson X-X-Sender: To: Brett Glass Cc: "Matthew D. Fuller" , Subject: Re: Lions and tigers and... chickens? In-Reply-To: <4.3.2.7.2.20011229182741.02ff21a0@localhost> Message-ID: <20011229230235.Q46948-100000@catalyst.sasknow.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Brett Glass wrote to Matthew D. Fuller and chat@FreeBSD.ORG: > At 07:24 PM 12/28/2001, Matthew D. Fuller wrote: > > >Suddenly, I was struck by a thought. How _DOES_ a vfork(2) chicken cross > >the road? > > > >Well, the beauty of it is, he doesn't have to; you just pretend he's on > >the other side. It's a lot quicker and easier, but if you want him to > >flap his wings, you have to build a new chicken from the ground up. > > Actually, it might be more accurate to say that an egg appears on > the other side of the road and you then have to hatch it. It is not necessary to exec() the chicken following a fork(). I think a more detailed outlook is required to get the full picture: Perhaps more correctly, we should say that when the chicken vfork()s, nothing really happens, but some normal chicken code gets executed. Assuming the normal chicken code doesn't change the state of the chicken, you have two chickens for the price of one. If one chicken so much as adjusts his beak, though, you're going to have siamese chickens. (As far as the universe is concerned, chickens are built using fixed-size hunks. The technical term for these is "nuggets"). Now, assuming the location of the chicken was stored by the chicken (and not in some Kentucky State variable outside of the chicken's space... or some pointer from the chicken to it's location, using GPS (global poultry satellite)). Come to think of it, it would be a bad design decision to have the chicken store its own location. For example, when the chicken dies, nobody remembers where the chicken was... Including crows looking for roadkill (garbage collection). Worse, the chicken has control over its own location, so it could instantaneously teleport, say, right before its neck goes to the butcher block. Still worse, another chicken could unknowingly set it's own location overlapping the first chicken, and you'd have yourself Kentucky Fried Chicken(TM)... Maybe even a Colonel panic![1]) Back to vfork()ing chickens. Suppose you've just vfork()ed this chicken... And you want it to cross the road. Well, if your universe is designed properly, you just change the new chicken's location globally (maybe with a Colonel call), and your new chicken (chicken B) appears on the other side of the road almost instantaneously. Both chickens are now doing the same chicken things, but not necessarily at the same time. (Chicken B, knows that it's a child of Chicken A, for instance, and can read it's global location variable, and realize that this ain't Kansas any more, and conclude that it no longer needs to think about crossing the road. Chicken A knows about Chicken B, and can now do other things. Chicken A better wait() for Chicken B, though, or if Chicken B gets run over, there'll be no one around to clean up, and you'll have a zombie chicken. [2] - Ryan [1] For far out of town folks, Kentucky Fried Chicken is a primarily North-American take-out fried chicken franchise. Their mascot is a funny guy called "The Colonel"]. [2] Better highways have volunteers that adopt sections of highway that nobody else wants, and clean up dead things. -- Ryan Thompson Network Administrator, Accounts SaskNow Technologies - http://www.sasknow.com #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message