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. Greetings, Andres Freund -- Andres Freund 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
