Re: [HACKERS] Current sources?

Tom Ivar Helbekkmo wrote:
>
> > I'm starting to look forward to when the CVS source tree gets into a
> > buildable state again! This could be a comfortable way of keeping
> > up to date with the current sources. Here's hoping you find a good
> > solution to the s_lock.h misunderstandings soon... :-)
>
> A closer look shows that you've actually got it worked out, except
> that the ugly hack for Sparcs running BSD now has broken completely.
> It used to work when it was in s_lock.h, but in a separately compiled
> file, it doesn't. (It relies on an entry point declared inside asm()
> within an unused function that's explicitly declared static.)

Ooops, sorry about that.

I guess I should have added a ".globl tas" or whatever the native asm phrase
for globalizing an entry point is and then it would have worked as I intended.

> I just replaced it with the simpler one for SparcLinux, and it's OK.

This is a very nice way to do this. In general, if we can count on having
GCC we should use the GCC inlines.

Hmmmm, on that note, the current sources are factored:

#if defined(linux)
#if defined(x86)
// x86 code
#else if defined(sparc)
// sparc code
#endif
#else
// all non linux
...
#endif

I think that the real commonality might better be expressed as:

#if defined(gcc)
// all gcc variants
#else
// no gcc
#endif

As GCC has a unique (but common to gcc!) "asm" facility. This would allow
all the free unixes and many of the comercial ones to share the same
asm implementation which should make it easier to get it right on all the
platforms.

Since I am planning another revision, does anyone object to this?

> On the weird side, after I updated to the current sources, the backend
> dies on me whenever I try to delete a database, whether from psql with
> 'drop database test' or from the command line with 'destroydb test'.

Try making the 's_lock_test' target in src/backend/storage/buffer/Makefile.
It will let you be sure that spinlocks are working.

Just btw, I have been doing some testing based on Bruce's reservations about
the inline vs call implementation of spinlocks, and will be posting an updated
set of patches and the results of my testing "real soon now".

Now that I have at least anoncvs access to the current tree, I think I can
do this with fewer iterations (crossing fingers...).

David Gould dg(at)illustra(dot)com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
"Of course, someone who knows more about this will correct me if I'm wrong,
and someone who knows less will correct me if I'm right."
--David Palmer (palmer(at)tybalt(dot)caltech(dot)edu)