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
Sure, but if people can't understand the API, then it's hard to decide
whether to be unhappy with it.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: