On Thu, Jun 26, 2014 at 7:21 AM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2014-06-25 20:22:31 -0400, Robert Haas wrote: >> On Wed, Jun 25, 2014 at 5:42 PM, Heikki Linnakangas >> <hlinnakan...@vmware.com> wrote: >> > I think having a separate file for each architecture is nice. I totally >> > agree that they don't belong in src/include/storage, though. s_lock.h has >> > always been misplaced there, but we've let it be for historical reasons, >> > but >> > now that we're adding a dozen new files, it's time to move them out. >> >> I find the current organization pretty confusing, but maybe that could >> be solved by better documentation of what's supposed to go in each >> architecture or compiler-dependent file. > > The idea is that first a architecture specific file (atomics-arch-*.h) > is included. That file can provide a (partial) implementation for the > specific architecture. Or it can do pretty much nothing. > > After that a compiler specific file is included > (atomics-generic-*.h). If atomics aren't yet implemented that can > provide an intrinsics based implementation if the compiler version has > support for it. At the very least a compiler barrier should be provided. > > After that the spinlock based fallback implementation > (atomics-fallback.h) provides atomics and barriers if not yet > available. By here we're sure that nothing else will provide them. > > Then we can provide operations (atomics-generic.h) that build ontop of > the provided functions. E.g. implement _sub, _and et al. > > I'll include some more of that explanation in the header.
I get the general principle, but I think it would be good to have one place that says something like: Each architecture must provide A and B, may provide both or neither of C and D, and may also any or all of E, F, and G. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers