-;;; Users: FORCE-CACHE-FLUSHES, MAKE-INSTANCES-OBSOLETE. Note that
-;;; it's not all certain this is sufficent for threadsafety: do we
-;;; just have to protect against simultaneous calls to these mutators,
-;;; or actually to stop normal slot access etc at the same time as one
-;;; of them runs
-
-#+sb-thread
-(progn
-(defstruct spinlock (value 0))
-(defvar *pcl-lock* (make-spinlock))
-
-(defmacro with-pcl-lock (&body body)
- `(progn
- (sb-thread::get-spinlock *pcl-lock* 1 (sb-thread::current-thread-id))
- (unwind-protect
- (progn ,@body)
- (setf (spinlock-value *pcl-lock*) 0))))
-);progn
-
-#-sb-thread
-(defmacro with-pcl-lock (&body body)
- `(progn ,@body))
+;;; PCL historically included a so-called method-fast-function, which
+;;; is essentially a method function but with (a) a precomputed
+;;; continuation for CALL-NEXT-METHOD and (b) a permutation vector for
+;;; slot access. [ FIXME: see if we can understand these two
+;;; optimizations before commit. ] However, the presence of the
+;;; fast-function meant that we violated AMOP and the effect of the
+;;; :FUNCTION initarg, and furthermore got to potentially confusing
+;;; situations where the function and the fast-function got out of
+;;; sync, so that calling (method-function method) with the defined
+;;; protocol would do different things from (call-method method) in
+;;; method combination.
+;;;
+;;; So we define this internal method function structure, which we use
+;;; when we create a method function ourselves. This means that we
+;;; can hang the various bits of information that we want off the
+;;; method function itself, and also that if a user overrides method
+;;; function creation there is no danger of having the system get
+;;; confused.
+(!defstruct-with-alternate-metaclass %method-function
+ :slot-names (fast-function name)
+ :boa-constructor %make-method-function
+ :superclass-name function
+ :metaclass-name static-classoid
+ :metaclass-constructor make-static-classoid
+ :dd-type funcallable-structure)
+