How to shower...

Discussion in 'Free Thoughts' started by *stRgrL*, Aug 1, 2002.

  1. thed IT Gopher Registered Senior Member

    Messages:
    1,105
    About the baby process

    BABY(1) USER COMMANDS BABY(1)

    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 a 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
    execution.

    Older implementations of baby did not require both initiating processes
    to be present at the time of completion. In those versions, the initiating
    process which was not present was awakened and notified of the results
    upon completion. It has since been determined that the presence of
    both parent processes results in generally lower system loads at the
    completion, and thus current versions of baby expect both parent
    processes to be active during the final stages.

    Successful completion of baby(1) 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
    % vital statistics: 8 pounds 3oz, 20 inches, dark hair
    % The parent process, 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 signal's cause.

    The sleep command may not work as expected on either parent process
    for some time afterward, as each new instance of baby sends intermittent
    signals to the parent processes which must be handled by the parents
    immediately.

    A baby process will frequently dump core, requiring either or both parent
    processes to clean up after it.

    Despite the reams of available documentation on invoking and maintaining
    baby, most parent processes are overwhelmed.

    BABY BUG REPORT:

    Mr. Dunbar distributed the man pages for baby(1) this morning. I wish
    to confirm some known bugs, give possible solutions, and to warn him
    of several undocumented bugs.

    We have also experienced the following undesirable behavior (as
    documented in the man pages) following the use of the baby(1)
    command using the syntax shown below:

    baby -sex f -name Beth (in 1989)
    baby -sex m -name Daniel (in 1991)

    For the first 1.552e+07 seconds after the child process was started,
    neither parent process was able to execute the sleep command when
    the argument exceeded 600. While this bug was noted in the baby
    man page, the man page clearly states that the child process will
    only send SIGCHLD signals. Experience demonstrated that the
    child process sent SIGURG signals as well as SIGCHLD signals,
    even though the conditions requiring urgent processind did not
    exist with the child process.

    Extensive research indicated that most signals were generally related
    to an I/O problem with the child process. In almost all cases, the
    signals indicated the child process either required input, or the
    output bin was full. In the case of the output bin full, the condition
    can be easily detected with the diapercheck(1) command using the
    -smell qualifier.

    However, in some cases, the child process continued to send the
    SIGURG signals for unknown reasons after the I/O problem was
    rectified. In these cases the kill(1) command was considered as
    a possible alternative, but was considered unacceptable by the
    system administrator.

    Additionally, we found that the first child process (-name Beth) began executing whine(2) continuously for no apparent reason beginning 1.5 years after the process startup. This condition appears to be ongoing even though the process has been running for 3.5 years. Unfortunately, it appears that this bug is getting steadily worse. The condition
    surrounding the bug is still being investigated, and no solution has been discovered to date.
     
  2. Guest Guest Advertisement



    to hide all adverts.
  3. BloodSuckingGerbile Master of Puppets Registered Senior Member

    Messages:
    440
    I don't remember putting a webcam in the shower and broadcasting myself over the internet...

    Please Register or Log in to view the hidden image!

     
  4. Guest Guest Advertisement



    to hide all adverts.
  5. Zero Banned Banned

    Messages:
    2,355
    That was so funny, post some more!!
     
  6. Guest Guest Advertisement



    to hide all adverts.

Share This Page