From owner-freebsd-questions@freebsd.org Wed Feb 1 21:52:48 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04CC8CCBEB6 for ; Wed, 1 Feb 2017 21:52:48 +0000 (UTC) (envelope-from bah@bananmonarki.se) Received: from feeder.usenet4all.se (1-1-1-38a.far.sth.bostream.se [82.182.32.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 658F219C9 for ; Wed, 1 Feb 2017 21:52:46 +0000 (UTC) (envelope-from bah@bananmonarki.se) Received: from [10.0.0.3] (testbox.usenet4all.se [10.0.0.3]) by feeder.usenet4all.se (8.13.1/8.13.1) with ESMTP id v11LqZQY027408 for ; Wed, 1 Feb 2017 22:52:36 +0100 (CET) (envelope-from bah@bananmonarki.se) Subject: Re: Programmer's Prayer To: freebsd-questions@freebsd.org References: From: Bernt Hansson Message-ID: <34620197-f8a2-fab2-a6b0-85788bebf505@bananmonarki.se> Date: Wed, 1 Feb 2017 22:52:35 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 21:52:48 -0000 On 2017-01-31 13:52, Gerard Seibert wrote: > PROGRAMMER’S PRAYER > > Our program, who art in memory, > called by thy name; > thy operating system run; > thy function be done at runtime > as it was in development. > > Give us this day our daily output. > and forgive us our code duplication, > as we forgive those who > duplicate code against us. > > And lead us not in frustration, > but deliver us from GOTOs. > > For thine is the algorithm, > the computation and the solution, > looping forever and ever. > > RETURN > NAME baby - create new process from two parents SYNOPSIS baby -sex [m|f] [-name name] DESCRIPTION baby is initiated when one parent process polls another server process through a socket connection in the BSD version or through pipes in the System V implementation. baby runs at low priority for approximately forty weeks and then terminates with a heavy system load. Most systems require constant monitoring when baby reaches its final stages of exe_ cution. Older implementations of baby did not require both initiating processes to be present at the time of completion. In those versions the initi_ ating process which was not present was awakened and notified of the results upon completion. It has since been determined that the pres_ ence of both parent processes result in a generally lower system load at completion, and thus current versions of baby expect both parent processes to be active during the final stages. Successful completion of baby results in the creation and naming of a new process. Parent processes then broadcast messages to all other processes, local and remote, informing them of their new status. OPTIONS -sex define the gender of the created process -name assign the name name to the new process EXAMPLES baby -sex f -name Jacqueline completed successfully on July 9, 1992 at 9:11pm. Jacqueline's vital statistics: 8 pounds 3 oz, 20 inches, long dark hair. The parent pro_ cess, Kim Dunbar, is reportedly doing fine. SEE ALSO cigar(6), dump(5), cry(3). BUGS Despite its complexity, baby only knows one signal, SIGCHLD, (or SIGCLD in the System V implementation), which it uses to contact the parent processes. One or both parent processes must then inspect the baby process to determine the cause of the signal. The sleep(1) command may not work as expected on either parent process for some time afterward, as each new instance of baby sends intermit_ tent signals to the parent processes which must be handled by the par_ ents immediately. A baby process will frequently dump core, requiring either or both par_ ent processes to clean up after it. Despite the reams of available documentation on invoking and maintain_ ing baby, most parent processes are overwhelmed. AUTHORS From a man page by Joe Beck, .