On 25 June 2012 20:59, Tom Lane wrote:
> Andres Freund writes:
>> Also, 'static inline' *is* C99 conforming as far as I can see?
>
> Hmm. I went back and re-read the C99 spec, and it looks like most of
> the headaches we had in the past with C99 inline are specific to the
> case where you want a
Andres Freund writes:
> On Monday, June 25, 2012 05:57:51 PM Tom Lane wrote:
>> Well, my response is "no". I could see saying that we require (some) C99
>> features at this point, but not features that are in no standard, no
>> matter how popular gcc might be.
> Also, 'static inline' *is* C99 co
On Monday, June 25, 2012 05:57:51 PM Tom Lane wrote:
> Andres Freund writes:
> > On Monday, June 25, 2012 05:15:43 PM Tom Lane wrote:
> >> So you propose to define any compiler that strictly implements C99 as
> >> not sensible and not one that will be able to compile Postgres?
> >
> > I propose t
Andres Freund writes:
> On Monday, June 25, 2012 05:15:43 PM Tom Lane wrote:
>> So you propose to define any compiler that strictly implements C99 as
>> not sensible and not one that will be able to compile Postgres?
> I propose to treat any compiler which has no way to get to equivalent
> behav
On Monday, June 25, 2012 05:15:43 PM Tom Lane wrote:
> Andres Freund writes:
> > On Friday, June 22, 2012 02:04:02 AM Tom Lane wrote:
> >> This is nonsense. There are at least three buildfarm machines running
> >> compilers that do not "pretend to be gcc" (at least, configure
> >> recognizes them
Andres Freund writes:
> On Friday, June 22, 2012 02:04:02 AM Tom Lane wrote:
>> This is nonsense. There are at least three buildfarm machines running
>> compilers that do not "pretend to be gcc" (at least, configure
>> recognizes them as not gcc) and are not MSVC either.
> Should there be no oth
Peter Geoghegan writes:
> On 22 June 2012 01:04, Tom Lane wrote:
>> This is nonsense. There are at least three buildfarm machines running
>> compilers that do not "pretend to be gcc" (at least, configure
>> recognizes them as not gcc) and are not MSVC either.
> So those three don't have medium
Andres Freund writes:
> On Friday, June 22, 2012 04:41:20 PM Tom Lane wrote:
>> Well, so does list.c, so I'd expect the performance risks to be similar.
> I don't think list.c does so:
Huh, OK. I seem to remember that the original version actually chased
down the whole list and verified that th
On Friday, June 22, 2012 04:41:20 PM Tom Lane wrote:
> Andres Freund writes:
> > Oh, I and Peter weren't talking about the pg_list.h stuff, it was about
> > my 'embedded list' implementation which started this subthread. The
> > pg_list.h/list.c stuff isn't problematic as far as I have seen in
> >
Andres Freund writes:
> Oh, I and Peter weren't talking about the pg_list.h stuff, it was about my
> 'embedded list' implementation which started this subthread. The
> pg_list.h/list.c stuff isn't problematic as far as I have seen in profiles;
> its checks are pretty simple so I do not find tha
On Friday, June 22, 2012 04:18:35 PM Tom Lane wrote:
> Andres Freund writes:
> > On Friday, June 22, 2012 12:23:57 AM Peter Geoghegan wrote:
> >> Why are you using the stdlib's ? Why have you used the
> >> NDEBUG macro rather than USE_ASSERT_CHECKING? This might make sense if
> >> the header was i
Andres Freund writes:
> On Friday, June 22, 2012 12:23:57 AM Peter Geoghegan wrote:
>> Why are you using the stdlib's ? Why have you used the
>> NDEBUG macro rather than USE_ASSERT_CHECKING? This might make sense if
>> the header was intended to live in port, but it isn't, right?
> That should pr
On Friday, June 22, 2012 02:04:02 AM Tom Lane wrote:
> Peter Geoghegan writes:
> > All of the less popular compilers we support we support precisely
> > because they pretend to be GCC, with the sole exception, as always, of
> > the Microsoft product, in this case MSVC.
>
> This is nonsense. Ther
On Friday, June 22, 2012 12:23:57 AM Peter Geoghegan wrote:
> On 20 June 2012 14:38, Andres Freund wrote:
> > It incurs a rather high performance overhead due to added memory
> > allocations and added pointer indirections. Thats fine for most of the
> > current users of the List interface, but cer
On 22 June 2012 01:04, Tom Lane wrote:
> This is nonsense. There are at least three buildfarm machines running
> compilers that do not "pretend to be gcc" (at least, configure
> recognizes them as not gcc) and are not MSVC either.
So those three don't have medium to high degrees of compatibility
Peter Geoghegan writes:
> All of the less popular compilers we support we support precisely
> because they pretend to be GCC, with the sole exception, as always, of
> the Microsoft product, in this case MSVC.
This is nonsense. There are at least three buildfarm machines running
compilers that do
On 20 June 2012 14:38, Andres Freund wrote:
> It incurs a rather high performance overhead due to added memory allocations
> and added pointer indirections. Thats fine for most of the current users of
> the List interface, but certainly not for all. In other places you cannot even
> have memory al
On Wednesday, June 20, 2012 03:24:58 PM Robert Haas wrote:
> On Wed, Jun 20, 2012 at 9:12 AM, Andres Freund
wrote:
> > Uh. I don't want to just go around and replace anything randomly.
> > Actually I don't want to change anything for now except whats necessary
> > to get the patch in. The point I
On Wed, Jun 20, 2012 at 9:12 AM, Andres Freund wrote:
> Uh. I don't want to just go around and replace anything randomly. Actually I
> don't want to change anything for now except whats necessary to get the patch
> in. The point I tried to make was just that the relatively widespread usage of
> si
On Wednesday, June 20, 2012 02:51:30 PM Robert Haas wrote:
> On Wed, Jun 20, 2012 at 6:59 AM, Andres Freund
wrote:
> >> Also, the performance-critical things
> >> could be reimplemented as macros.
> >>
> >> I question, though, whether we really need both single and doubly linked
> >> lists. Tha
On Wed, Jun 20, 2012 at 6:59 AM, Andres Freund wrote:
>> My guess is that it wouldn't be too hard to remove some of the extra
>> pointers. Anyone who is using Dllist as a non-inline list could be
>> converted to List * instead.
> There are only three users of the whole dllist.h. Catcache, autovac
On Wednesday, June 20, 2012 05:01:16 AM Robert Haas wrote:
> On Tue, Jun 19, 2012 at 4:22 PM, Andres Freund
wrote:
> >> > 1. dllist.h has double the element overhead by having an inline value
> >> > pointer (which is not needed when embedding) and a pointer to the list
> >> > (which I have a hard
On Tue, Jun 19, 2012 at 4:22 PM, Andres Freund wrote:
>> > 1. dllist.h has double the element overhead by having an inline value
>> > pointer (which is not needed when embedding) and a pointer to the list
>> > (which I have a hard time seing as being useful)
>> > 2. only double linked list, mine p
On Tuesday, June 19, 2012 09:58:43 PM Robert Haas wrote:
> On Tue, Jun 19, 2012 at 3:48 PM, Andres Freund
wrote:
> > Why is that code not used more widely? Quite a bit of our list usage
> > should be replaced embedding list element in larger structs imo. There
> > are also open- coded inline list
On Tue, Jun 19, 2012 at 11:02 PM, Andres Freund wrote:
> On Tuesday, June 19, 2012 09:59:48 PM Marko Kreen wrote:
>> On Wed, Jun 13, 2012 at 2:28 PM, Andres Freund
> wrote:
>> > +/*
>> > + * removes a node from a list
>> > + * Attention: O(n)
>> > + */
>> > +static inline void ilist_s_remove(ilis
Hi,
On Tuesday, June 19, 2012 09:59:48 PM Marko Kreen wrote:
> On Wed, Jun 13, 2012 at 2:28 PM, Andres Freund
wrote:
> > +/*
> > + * removes a node from a list
> > + * Attention: O(n)
> > + */
> > +static inline void ilist_s_remove(ilist_s_head *head,
> > + ilist
On Wed, Jun 13, 2012 at 2:28 PM, Andres Freund wrote:
> +/*
> + * removes a node from a list
> + * Attention: O(n)
> + */
> +static inline void ilist_s_remove(ilist_s_head *head,
> + ilist_s_node *node)
> +{
> + ilist_s_node *last = &head->head;
> + ili
On Tue, Jun 19, 2012 at 3:48 PM, Andres Freund wrote:
> Why is that code not used more widely? Quite a bit of our list usage should be
> replaced embedding list element in larger structs imo. There are also open-
> coded inline list manipulations around (check aset.c for example).
Because we've g
On Tuesday, June 19, 2012 09:16:41 PM Robert Haas wrote:
> On Wed, Jun 13, 2012 at 7:28 AM, Andres Freund
wrote:
> > Adds a single and a double linked list which can easily embedded into
> > other datastructures and can be used without any additional allocations.
>
> dllist.h advertises that it'
On Wed, Jun 13, 2012 at 7:28 AM, Andres Freund wrote:
> Adds a single and a double linked list which can easily embedded into other
> datastructures and can be used without any additional allocations.
dllist.h advertises that it's embeddable. Can you use that instead,
or enhance it slightly to s
From: Andres Freund
Adds a single and a double linked list which can easily embedded into other
datastructures and can be used without any additional allocations.
Problematic: It requires USE_INLINE to be used. It could be remade to fallback
to to externally defined functions if that is not avai
31 matches
Mail list logo
