From owner-freebsd-hackers Fri Aug 25 3:14: 2 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from user2.hushmail.com (user2.hushmail.com [216.18.8.74]) by hub.freebsd.org (Postfix) with ESMTP id C42C537B424 for ; Fri, 25 Aug 2000 03:13:58 -0700 (PDT) Received: (from root@localhost) by user2.hushmail.com (8.9.3/8.9.3) id DAA14106; Fri, 25 Aug 2000 03:12:41 -0700 From: core-ix@hushmail.com Message-Id: <200008251012.DAA14106@user2.hushmail.com> Date: Чт, 25 VIII 2000 13:12:13 +0200 (EEDT) Cc: To: freebsd-hackers@FreeBSD.ORG Mime-version: 1.0 Content-type: multipart/mixed; boundary="Hushpart_boundary_XVfBISCSfQomtkHiyjTkbtSNezCOjdha" Subject: Preventing zombies to occure Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --Hushpart_boundary_XVfBISCSfQomtkHiyjTkbtSNezCOjdha Content-type: text/plain Hello, I have some ideas to improve fork()-ing and getting rid of zombie processes. This things mentioned here are proposed of a man that do not know very well (author means 'the depths' of) BSD kernel source although he have some ex- pirience with it (mainly in reading it :-). By definition zombie is a process entry in proc table that wasn't released by wait*() called form the parent's code. So all we need to do is to ensure that parent will call wait*() as many times as it called fork(). This meth- od have some advantages but it has some disadvantages too. First of all, we provide programmers & all users with full out-of-zombies enviroment where everything created will be destroyed in the right way. Second, proposed me- thod is easy to include in current source with minnor modifications. What I exactly mean is: 1) Adding 'int childs' field in 'struct proc' in /usr/src/sys/sys/proc.h That field will store current numbers of childs for the process entry. After creation of process it is initialized to zero and incremented by one after each fork(). The real incrementation may be done by *fork() or fork1() from /usr/src/sys/kern/kern_fork.c - it doesn't matter. In this way we may keep track of number of childs; how many times process fork()s; to limit number of fork()s per process and etc. 2) Setting up an 'at-exit()' function that will call wait*() as many ti- mes as needed. It could probably look something like that: void release_childs(p) struct proc *p; { int rc; while(p->childs != 0) /* Release all childs in a loop by { * wait()-ing each of them to exit rc = wait(NULL);*/ if(rc == -1) { printf(" Can NOT release all childs \n"); /* * Any other steps to proceed here */ return; } p->childs--; /* Decreasing the number of childs left*/ } return; } And the code to call the above somewhere in fork1() (probably): . . . at_exit(release_childs()); . . . 3) Of course, any program may still use wait*() functions to ensure right exiting of each childs, but the new wait*() functions should include some bits of code like this (probably the right place for it is /usr/src/sys/kern/kern_ exit.c --> wait1()): . . . q->childs--; . . . By doing this, the code will take care only for childs that wasn't wait()- ed or 'forgotten' by the parent process due to programmer's mistake or bad algorithm. This code probably may be improved a lot but for now it is still in 0.1 version :-) so please excuse my "kernel-C". (All mentioned-bug comments are wellcome). That's all by now. If you think there is something usefull in the ideas menti- oned above please drop me a letter to encourage me. I am unix new programmer with little experience but I'd like to help anyone that develops BSD and espe- cially FreeBSD by introdusing ideas that I found worthable in my works. Please excuse my code if it isn't as tight as it should be but I am only 18-years- old high-school student with interests in OS development and almost any information about it. (If you can, send me any kind of programming resources oriented to BSD and other Unices). Thanks for reading this long borring letter. Looking forward to hearing from you. ix core-ix@hushmail.com --Hushpart_boundary_XVfBISCSfQomtkHiyjTkbtSNezCOjdha-- IMPORTANT NOTICE: If you are not using HushMail, this message could have been read easily by the many people who have access to your open personal email messages. Get your FREE, totally secure email address at http://www.hushmail.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message