Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!stc!ct
From: ct@tcom.stc.co.uk (Clive Thomson)
Newsgroups: comp.unix.questions
Subject: Some questions
Keywords: death of child, file descriptors, bind
Message-ID: <1716@jura.tcom.stc.co.uk>
Date: 28 Jun 90 11:00:26 GMT
Organization: STC TSD-E, Access Systems Engineering, Harlow. ESSEX
Lines: 36



Hello,

I have recently started the long journey that will hopefully lead to UN*X
enlightenment, and have some questions I hope somebody will answer for me.

1) The document for the dup call says that it will return the lowest numbered
   file descriptor not used by the process. With the exception of one line
   in "The design and implementation of the BSD 4.3 UNIX operating system"
   (Leffler et al) I have seen no documentation to say open, creat and socket
   will do the same. Observation of open seems to suggest that the lowest fd
   is used, but I would like to be sure.

2) When I am doing socket programming (ULTRIX 3.0 and SunOS4), and I do a 
   bind, if the program terminates abnormally, I find that when I re-run the
   program the bind will fail with an "in use" error. Is there any way to
   convince the system that it is no longer "in use" (assuming of course 
   uid, gid etc are the same).

3) I am a little confused by the "death of child signal". Is the following
   correct. If the parent ignores this signal, the kernel will release
   entries for zombie processes automatically. If the parent uses the default
   handler, it must wait() for the death of each child, or the child will
   become a zombie. If the parent invokes its own handler, in this handler
   a wait should be invoked, otherwise the child will become a zombie. If
   the parent dies before the children, all children are adopted by the init
   process, and the programmer need no longer worry about zombie processes.

Thanks for your time.

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+   Clive Thomson                                   ...!mcvax!ukc!stc!ct     +
+                                                      ct@tcom.stc.co.uk     +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++