On Tue, Nov 19, 2013 at 10:26 AM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2013-11-19 09:12:42 -0500, Robert Haas wrote: >> On point #1, I dunno. It looks like a lot of rearrangement to me, and >> I'm not really sure what the final form of it is intended to be. > > Understandable. I am not that sure what parts we want to rearange > either. We very well could leave barrier.h and s_lock.h untouched and > just maintain the atomics stuff in parallel and switch over at some > later point. > I've mainly switched over s_lock.h to a) get some good coverage of the > atomics code b) make sure the api works fine for it. We could add the > atomics.h based implementation as a fallback for the cases in which no > native implementation is available. > >> I think it desperately needs a README explaining what the point of all >> this is and how to add support for a new platform or compiler if yours >> doesn't work. > > Ok, I'll work on that. It would be useful to get feedback on the > "frontend" API in atomics.h though. If people are unhappy with the API > it might very well change how we can implement the API on different > architectures.
Sure, but if people can't understand the API, then it's hard to decide whether to be unhappy with it. -- 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
