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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to