Date: Wed, 25 Jun 2014 18:04:48 -0400
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: Andres Freund <andres@2ndquadrant.com>,
 Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
 Peter Geoghegan <pg@heroku.com>, Pg Hackers <pgsql-hackers@postgresql.org>,
 Ants Aasma <ants@cybertec.at>
Subject: Re: better atomics - v0.5
Message-ID: <20140625220448.GI7340@eldon.alvh.no-ip.org>
References: 
 <CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com>
 <20140625171434.GG24114@awork2.anarazel.de>
 <CA+TgmoZShVVqjaKUL6P3kDvZVPibtgkzoti3M+Fvvjg5V+XJ0A@mail.gmail.com>
 <20140625203635.GJ24114@awork2.anarazel.de>
 <53AB424D.8030306@vmware.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <53AB424D.8030306@vmware.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Heikki Linnakangas wrote:
> On 06/25/2014 11:36 PM, Andres Freund wrote:
> >
> >>>- I completely loathe the file layout you've proposed in
> >>>src/include/storage.  If we're going to have separate #include files
> >>>for each architecture (and I'd rather we didn't go that route, because
> >>>it's messy and unlike what we have now), then shouldn't that stuff go
> >>>in src/include/port or a new directory src/include/port/atomics?
> >>>Polluting src/include/storage with a whole bunch of files called
> >>>atomics-whatever.h strikes me as completely ugly, and there's a lot of
> >>>duplicate code in there.
> >I don't mind moving it somewhere else and it's easy enough to change.
> 
> 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.

We also have a bunch of files in src/backend/storage/lmgr, both current
and introduced by this patch, which would be good to relocate.  (Really,
how did lmgr/ end up in storage/ in the first place?)

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers