Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!rpi!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!chinacat!sequoia!rpp386!jfh From: jfh@rpp386.cactus.org (John F. Haugh II) Newsgroups: comp.unix.wizards Subject: Re: Is System V.4 fork reliable? Message-ID: <18478@rpp386.cactus.org> Date: 29 Jul 90 21:48:23 GMT References: <561@oglvee.UUCP> <480@amanue.UUCP> <13426@cbmvax.commodore.com> <573@oglvee.UUCP> Reply-To: jfh@rpp386.cactus.org (John F. Haugh II) Organization: Lone Star Cafe and BBS Service Lines: 21 X-Clever-Slogan: Recycle or Die. In article peter@ficc.ferranti.com (Peter da Silva) writes: >In article <573@oglvee.UUCP> jr@oglvee.UUCP (Jim Rosenberg) writes: >> The larger question is *why can't the kernel sleep* when it needs more memory >> for a fork??? >Even if it can't do it right then, it could check right before leaving >kernel mode. Or if that's politically incorrect, change fork.o in libc.a >to implement the check for EAGAIN and do an exponential backoff (or >whatever). It isn't that the kernel =can't= sleep, but rather that someone decided [ for some totally random reason, I suspect ... ] that the kernel =shouldn't= sleep. The solution isn't to add some kludge on top of the system, but rather to put back the behavior that was always there - the kernel sleeps in fork if it requires additional memory. In the past, the kernel swapped the process if malloc() didn't return with space. So, this is a change in function, not some defect in application code. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org