SYSTEM command

[Bill Vermillion]

On Sat, Nov 20 13:45 , Fairlight moved his mouse, rebooted for the 
change to take effect, and then said:" 

> Confusious (Kenneth Brody) say:
> > Fairlight wrote:

> > > You'll never BELIEVE what Kenneth Brody said here...:

> > > > > Yes, but you will then need to make sure you exit from
> > > > > the loop, otherwise you will have a zombie on your
> > > > > hands :-)

> > > > The loop will exit when the read fails, which will happen
> > > > when filePro closes the pipe to it.

> > > You'll possibly still end up with a zombie. A client of
> > > mine once -insisted- that having one rclerk continuously
> > > running to handle CGI requests and then forking off other
> > > rclerk processes to handle the details was a good model.
> > > His process tables got filled with zombies from this model.
> > > AFAICT, fP doesn't wait on SIGCHLD, and you'll have a
> > > zombie until the clerk or report process itself goes away
> > > and takes its children with it for good.

> > A zombie is created when a process dies and its parent
> > doesn't wait for it. Don't die until filePro tells you to,
> > and you won't have zombies.

> Ken, that has to be the silliest statement I've ever seen you
> make. What we should just leave useless processes sleeping?
> This statement of yours sounds tantamount to, "We didn't feel
> like coding a < 5 line signal handler, so Don't Do That." That
> doesn't cut it, sorry.

Well technically it is not 'sleeping' but is 'dead' and doesn't
know it yet.  In OSR5 if there are zombies processes and it's
parent is 'init' the same as an adopted orphan, the zombie will go
away by itself.    If the parent isn't init you have to kill
the parent which is probalby not what you want.

And they aren't consuming any resources except a slot in the
process table.  In most modern Unixen you aren't going to
have any problems unless you start seeing hundreds or perhaps
thousands of zombies.

Of coure there are operating systems where a  -z  flag to 
killall will get rid of the 'the living dead'.

> The entire point of discussing the proposed model's capacity
> for generating zombies is to warn people that they could
> quickly fill their process ID table if they're not careful in
> how they code it under the current implementation.

And of course that depends upon just how large their process table
space is.   

> The main thrust of this post is that the application should never allow
> this to happen in the first place.  There shouldn't -be- a need to worry
> about it at all.  It's a 4GL, right?  The user shouldn't have to worry
> about this kind of easily preventable "gotcha".

Correct on the 'should never allow this to happen in the first
place'.

Bill
-- 
Bill Vermillion - bv @ wjv . com