Re: [HACKERS] s_lock.h busted

>
> The weekend's hacking on s_lock.h broke it for all platforms that
> need non-default definitions of S_UNLOCK or S_INIT_LOCK (hpux,
> alpha, a couple others). Someone put unconditional definitions
> of those macros at the bottom of the file. I suspect this was a
> plain old editing typo, but perhaps the intent was to put such
> definitions in one of the platform-specific #if blocks? (If so,
> they were unnecessary anyway.) Anyhow, the attached patch fixes
> it for hpux.
>
> regards, tom lane
>
>
> *** src/include/storage/s_lock.h.orig Mon Jul 20 12:05:59 1998
> --- src/include/storage/s_lock.h Mon Jul 20 13:04:49 1998
> ***************
> *** 323,332 ****
> #define TAS(lock) tas((volatile slock_t *) lock)
> #endif /* TAS */
>
> - #define S_UNLOCK(lock) (*(lock) = 0)
> -
> - #define S_INIT_LOCK(lock) S_UNLOCK(lock)
> -
>
> #endif /* HAS_TEST_AND_SET */
> #endif /* S_LOCK_H */
> --- 323,328 ----
>

Arrrrgggghhh!!!!

Ok, I'm calmer now...

These were meant to be in the conditional blocks at the end of the file so
that if (and only if) no definition existed we would get a default. So:

#ifndef S_UNLOCK
#define S_UNLOCK(lock) (*(lock) = 0)
#endif

#ifndef S_INIT_LOCK
#define S_INIT_LOCK(lock) S_UNLOCK(lock)
#endif

I am a little concerned about the recent batch of patches made to this code.
I was planning a cleanup patch to resolve all the issues raised, but kept
seeing other patches and since I got badly burned by a merge conflict I was
hoping it would settle down a little. Sigh...

Perhaps I need to pull the latest tree again and see where we have gotten
to.

-dg

David Gould dg(at)illustra(dot)com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
- If simplicity worked, the world would be overrun with insects. -