Date: Mon, 07 Aug 2000 22:56:25 +0100 From: Paul Richards <paul@originative.co.uk> To: dg@root.com Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Alfred Perlstein <bright@wintelcom.net>, Matt Dillon <dillon@earth.backplane.com>, Mike Smith <msmith@FreeBSD.ORG>, Stephen McKay <mckay@thehub.com.au>, freebsd-current@FreeBSD.ORG, dillon@FreeBSD.ORG Subject: Re: Ugly, slow shutdown Message-ID: <398F3089.416DEA1@originative.co.uk> References: <200008071903.MAA03649@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Greenman wrote: > > >>Can you give a reason why we'll have to now start coding defensively > >>because our arguments to tsleep() are just "advisory" now? > > > >It is not something we "suddenly have to do" it's been The Right Way > >even since I first sharpened my teeth on unix kernels many years ago. > > Uh, Poul, I think you're full of it. The previous behavior of tsleep where > you can make assumptions about who wakes you and under what conditions is a > long and well established idiom. We (the kernel developers of BSD) have always > coded to the established kernel programming interface and most of us consider > it bad form to check for conditions which can't happen because the kernel > API doesn't allow it. For example, we don't check for a NULL return from malloc > in the case of !NO_WAIT, because we knew that the code would never do that. > There are many other examples of similar assumptions in the kernel. We write > the code to be efficient and only check for bogus conditions that might > happen. The only exception to this is programatic ASSERTs that do internal > consistency checks, but the purpose of those is quite different. In the particular case of sleeping though, a woken process does need to check the condition that it slept on because one of the other processes sleeping on that resource may have had a chance to run first and changed some state. So as a general rule, you shouldn't assume that everything is fine when you return from being asleep because it might not be. I agree with your sentiment about defensive coding in the kernel though. Defensive coding should only be used on the boundary of your interface, i.e. if you're getting non-deterministic data from somewhere, most commonly user behaviour. Everything inside the kernel implementation should be deterministic and therefore there shouldn't be any need for defensive programming. Any cause of errors that defensive programming catches in the kernel can only be caused by bugs and therefore falls into the category of diagnostics. There's actually a lot of defensive programming creeping into the kernel which should really be wrapped in an #ifdef INVARIANTS. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?398F3089.416DEA1>