Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!news.ececs.uc.edu!news.kei.com!newsfeed.internetmci.com!news-in2.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: What is a zombie?
Date: Sat, 12 Oct 1996 17:23:07 -0700
Organization: Me
Lines: 175
Message-ID: <3260366B.5041524A@lambert.org>
References: <52a5dt$qef@vixen.cso.uiuc.edu> <3249D8F7.2EA39DDA@lambert.org>
<52jtk1$8s@uriah.heep.sax.de> <324F080E.4BFCA0F@lambert.org>
<52nr0k$baa@uriah.heep.sax.de> <32501DAC.2BEEACF9@lambert.org>
<5361v2$ba@uriah.heep.sax.de> <3256F5F4.7217ACEC@lambert.org> <538i6u$823@uriah.heep.sax.de>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
J Wunsch wrote:
] > If there were some assurances (like no outstanding PR's over a
] > certain age) that the code would even be looked at, I *might*
] > be willing to tackle an implementation of SA_NOCLDWAIT.
]
] There are outstanding PRs for things where nobody is working on, or
] for things where nobody can reproduce the problem or even has at least
] the hardware for it. There are certainly many stale PRs, where the
] problem has already been solved since as the side-effect for something
] else.
There are also outstanding PR's for things like NFS locking and
other problems for which I have submitted fixes, which remain
unintegrated. This tends to disincent me from submitting things
which I don't feel strongly about.
] In this case, i'm already intersted in persuing this, Bruce is also
] watching the discussion, so the expected time for your PR to be
] incorporated will be low if the fix concentrates on the fix itself
Nice to know that we've established a link into "the good old
boy network" for this one problem. Pity it is not as easy for
all problems. Too bad the interest of a person on the core team
is required as part of the fix integration process.
] (i.e., without revamping 30 files for cosmetic changes,
This would be a reference to my FS layering fixes, which included
SMP single-entry/single-exit changes as preliminary support for
kernel reentrancy.
These are hardly cosmetic changes, even if you insist on taking
them out of context and considering only one change area at a
time.
It has only been very recently, with the advent of CVSSup, that
local multiple branch maintenance for developers without commit
access to the FreeBSD tree has even been possible at all. Since
my change predates that change in FreeBSD's sorce code control
architecture, it is grossly unfair for you to hold me up to that
artificially high standard.
Note that, like the failed FreeBSD/NetBSD merge, and the later
NetBSD/OpenBSD split, this is largely an issue of control and
kingdom building, and there is no good technical reason for
architecting the process this way; in fact there are good
technical reasons for *not* architecting the process this
way.
] elimination of goto's, etc. :)
Ah. A veiled reference to the init_main.c changes which I
implemented to modularize system startup, which were provided
in alpha form, and which were integrated with the FreeBSD source
tree over both my grave reservations and my loud objections.
I might be culpable for complaints of "dangerous goto use" IF:
1) I had suggested integration rather than simply
proposing the changes for testing and:
2) Goto's were truly any more evil in my code than in
the vfs_syscalls.c code, where they continue to exist
in defiance of a policy of implementing such control
flow using negative logic. We all know that "goto label"
is a hell of a lot more specific than "break; <no label>"
and the the compiler is going to emit "goto's" in the
form of conditional jump instructions anyway, but I
guess if you don't see them, then they aren't evil.
In short, get over "goto"; the only example you can cite for
it is invalid, and it would be nice if you would quit trying
to support your prejudices with arguments based on false logic.
] > Of course the problem is trivially solvable by making the
] > distinction between SIG_IGN and SIG_DFL instead, without
] > dragging in all of the overdesigned mass which happens to
] > include SA_NOCLDWAIT.
]
] Again, you don't know what you're talking about. You haven't even
] looked into the code. Even 20 minutes of experimenting with any of it
] would have shown you that your statements are wrong.
Yet SCR3 continues to function correctly in open defiance of your
claims. Either USL has defied the laws of logic and nature (in
which case, truly, the USL code contains trade secrets!), or there
is more than one way, your preferred way, to solve a problem.
] I did look, so either believe it, or prove me wrong.
I worked on similar code at Novell/USG (the former USL). Since
they invented UNIX in the first place, and much of the POSIX
standards are simply an expansion of SVID III as a political
appeasment of the UNIX "powers that be" at the time (how else do
you explaim "mkfifo" and the lack of file extension/truncation
primitives?), I suspect my 13 year association with the UNIX
kernel sources places me in a better position to consider
alternate implementation than you -- correct me if I'm wrong
here, and you have more experience than me?
] The question whether to implement SA_NOCLDWAIT, or make a
] distinction between SIG_IGN and SIG_DFL is a minor
] implementation detail. It's in no way related to the actual
] problem itself (which i leave out as an exercise for the
] reader unless somebody pops up who explains me that he's got
] seriously interested in helping to implement this feature).
All of this *crap* derives from the initial signal handling
decision for tty and job control signal handling, and non
propagation of SIGHUP, et. al., a decision made in the dim
past with, I personally believe, an incorrect semantic
interpretation of the POSIX standard of the time (1003.1-1988).
If you insist on maintaining this (broken) interpretation of
the standard, then *yes*, it is an implementation detail, and
the problem is "hard".
I have argued in the past (unsuccessfully, in spite of the
many complaints of the user world about "read" returning 0
and processes which were not controlling processes for tty's
not getting a correct SIGHUP -- the answer has always been
"check the return status from the read, we aren't going to
fix the signal code) that the signal code is incorrectly
implemented.
What you suggest is further digression in this incorrect
direction, with increasingly grave sosequences (of which the
current topic of discussion is one) the futrther the code moves
from the *correct* interpretation to the creative interpretation
of POSIX signal semantics which seems to hold sway in the FreeBSD
camp.
In short, you are insisting on winning an argument by causing
me to agree to a solution which is a consequence of an already
*incorrect* solution to the larger problem.
Thank you, but no thanks.
] Actually, the SA_NOCLDWAIT implementation itself was really an
] easy one... It took some 5 minutes (3 of them for a major
] recompilation of the kernel since i changed a central .h file).
] The problems are elsewhere.
Only if you insist, as a major premise, that the signal code
"proper" must not be touched by the implementation of the
handling code, and that the change must go there instead.
This is a provably incorrect (ie: there are historical
implementations in the USL code base which function in defiance
of your mandates).
If you are willing to *consider* a framework change, I would
*consider* discussing the *right* soloution to the *actual*
problem with you at your (and my) convenience.
Until such time, good luck in resolving this subproblem instance
in your unnecessarily restricted problem framework.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.