Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!metro!cluster!necisa!boyd
From: boyd@necisa.ho.necisa.oz (Boyd Roberts)
Newsgroups: comp.unix.wizards
Subject: Re: Who is responsible for a retry (was Re: Is System V.4 fork reliable?)
Message-ID: <1809@necisa.ho.necisa.oz>
Date: 30 Jul 90 23:56:00 GMT
References: <561@oglvee.UUCP> <480@amanue.UUCP> <13426@cbmvax.commodore.com> <573@oglvee.UUCP> <7885@tekgvs.LABS.TEK.COM> <866@mwtech.UUCP>
Organization: NEC Information Systems Australia Pty. Ltd.
Lines: 29

When fork() fails with EAGAIN it fails for a good reason.

How many lines of user-mode code does it take to code up retries?

About 20.

It would seem that there is some consensus to change the semantics of
fork() to retry.  This would break a critical interface.  System calls
do one thing, and one thing well.  A trivial addition to user-mode programs 
is what is required, and NOT the re-definition of a well defined critical
interface.

Leave the kernel and C library alone.  Write your own re-trying fork().

    NAME

	bork() - spawn new process with exponential backoff on failure

    SYNOPSIS

	int bork(retries)
	int retries; 

    ...


Boyd Roberts			boyd@necisa.ho.necisa.oz.au

``When the going gets wierd, the weird turn pro...''