From: Nikodemus S. <nik...@ra...> - 2009-04-26 13:00:11
|
2009/4/26 Faré <fa...@gm...>: > Following this line of reasoning, even DEFVAR would be bad > unless DEFVAR itself is atomic between the moment it checks for boundp > and the moment it commits the new value. Um. I find that a fairly extreme position. I think it's reasonable to assume that you may during development be reloading code that happens to have things like (defvar *lock* (make-mutex)) in it while threads holding those locks are running, in which case DEFVAR does TRT -- keeps the old lock in place instead of nuking it. While DEFVAR without a global lock is certainly racy when it comes to boundness checking, I think it's clear that encountering the boundness race in the real world is infinitely rarer than the case outlined above: it requires you to load code in parallel instead of just developing while your application is running. *** At any rate the core point is that DEFGLOBAL is analogous to DEFVAR in the sense that is does not evaluate if the variable is already bound, making it a drop-in replacement for it when rebinding is not needed. *** > But then again, I don't understand defglobal in the context of this > remark. Will DEFGLOBAL prevent re-binding just like DEFCONSTANT? Then > what does it do that DEFCONSTANT doesn't? Or if it does allow > re-binding, isn't it just as bad as DEFPARAMETER in the context of > your remark? Or will it only allow re-binding with SETF, and treat any > subsequent DEFGLOBAL as either an error or a nop? I'm confused. There is terminology confusion here: when I say "rebinding" I mean LET, PROGV, LAMBDA, etc. DEFGLOBAL prevents rebinding like DEFCONSTANT. It also prohibits MAKUNBOUND. Re-evaluating a it is a nop. SETF is allowed. Cheers, -- Nikodemus |