[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
SAFEty and the Cross Referencing of BLASTs
- To: <tribble@xxxxxxxxxxx>
- Subject: SAFEty and the Cross Referencing of BLASTs
- From: Mark S. Miller <vlad!mark>
- Date: Wed, 5 Dec 90 22:01:52 PST
- Cc: <xtech@xxxxxxxxxxx>
- In-reply-to: <Eric>,16 PST <9012031939.AA13316@xanadu>
Date: Mon, 3 Dec 90 11:39:16 PST
From: xanadu!tribble (Eric Dean Tribble)
All SAFE methods can be NOLOCK, and some methods that are not SAFE
will be NOLOCK (the splay routines in particular).
I see. Makes sense. SAFE implies NOLOCK. SAFE also implies NOFAULT.
Is there any such relationship between NOLOCK and NOFAULT?
SAFE strikes me something like a type declaration: a particular
implementation is not safe unless all subclass implementations are
safe (because they could be transparently substituted.
Yes, it is exactly like a type declaration. It is a contractual
obligation which is inherited by subclasses, and which is statically
checked when a client needs something he's invoking to be SAFE
(because the invokation is happening from a SAFE routine). This also
gives SAFE checking the kind of compositional flavor that one
associates with type checking.