Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!mcsun!unido!mikros!mwtech!martin
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.unix.wizards
Subject: Re: Is System V.4 fork reliable?
Message-ID: <865@mwtech.UUCP>
Date: 29 Jul 90 13:48:10 GMT
References: <480@amanue.UUCP> <13426@cbmvax.commodore.com> <573@oglvee.UUCP> <13435@smoke.BRL.MIL>
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany
Lines: 49

In article <13435@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>In article <573@oglvee.UUCP> jr@oglvee.UUCP (Jim Rosenberg) writes:
>-But if system calls fail simply because of a very temporary bout of activity,
>-that is *not my problem*!  It's the kernel's problem.  At least it should be:
>-that's what "I'm paying the kernel for" so to speak.  And *I CAN'T FIX IT*
>-myself.  If utilities haven't been rewritten to do the right thing with EAGAIN
>-after fork(), and I'm only a binary licensee, what can I do about it?
>
>Oh, good grief.  It is SILLY to say that the kernel should be redesigned
>to compensate for bugs in application programs.

Would you write the same, if someone sold a disk controller with a
firmware problem that causes it sometimes to give erratic answers,
until, say, the head happens to cross track 512, after which everthing
runs normal again? Suppose further this erratic behaviour is even
documented somewhere in the controller manual. Would you support the
view of the controller manufacturer who might say:

	"In fact, my controller is working PERFECTLY WELL, it's all
	the problem of those who haven't read the docs which tells
	about this. It's SILLY to say I should redesign the firmware
	to compensate for bugs in device drivers of UNIX, which should
	just make more retries if this particular problems shows up.
	As the DOS-driver I supply with my controller shows, there's
	no problem with my controller if you use it in the right way."

Well, if I put myself in the shoes of that particular manufacturer, I
could even take this view. If I put myself into the shoes of a kernal
code developper, I can well understand Doug Gwyn's view (and from the
many knowledgable answers and worthful contributions Doug has posted
to this group, I think his view *is* the one of a person who knows kernal
stuff more than well).

But I'm in the position of an application developper and as such I
take the view of the original poster, who's opinion is that a solution
for this problem belongs into the kernal.

Oh ... wait a moment, my telephone just rings ...

"Who's there, Joe Customer? What, the program I sold you behaves
erratic. Ehmm, just retry some times ... and btw. read the docs.
On page 277 you'll find a footnote that tells you that you should
just retry ...".

OK, here I'm back again. Oh folks, these SILLY customers! They allways
want me to redesign this complex program, just because they can't use
it in the right way ... :-)
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83