From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
To: Petr Jelinek <petr@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: John Gorman <johngorman2@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: PATCH: two slab-like memory allocators
Date: Thu, 1 Dec 2016 03:26:56 +0100
Message-ID: <40888631-2761-6eaa-e76f-3fdf7a09bd03@2ndquadrant.com> (raw)
In-Reply-To: <20161127220214.v5fnwccwtxwq5jih@alap3.anarazel.de>
References: <a4593432-c989-8ec4-2320-943e3f97ce6d@2ndquadrant.com>
<CA+TgmobJrM74FRTcmn2JDMVbLB0a5pj5e3ieLBMzkDNtrxF4dw@mail.gmail.com>
<9818b54a-fcb6-f018-0b16-96d6a1d1da27@2ndquadrant.com>
<34a6d4ea-7f3d-a62c-fff1-7a9108c078d7@2ndquadrant.com>
<f2aaf4a5-412c-a4b9-389d-c9f682fbdc77@2ndquadrant.com>
<4f176a6c-c197-165d-dee4-5de8f279f1f4@2ndquadrant.com>
<20161112191257.3a4n6kzegvu637qn@alap3.anarazel.de>
<efd47210-cf95-d7ee-e984-a873f76596a8@2ndquadrant.com>
<20161127204740.dr3swudwsbafjuof@alap3.anarazel.de>
<a4b35a6e-7b8a-1550-1543-e5e77183ab5f@2ndquadrant.com>
<20161127220214.v5fnwccwtxwq5jih@alap3.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Dne 11/27/2016 v 11:02 PM Andres Freund napsal(a):
> On 2016-11-27 22:21:49 +0100, Petr Jelinek wrote:
>> On 27/11/16 21:47, Andres Freund wrote:
>>> Hi,
>>>
>>>>> +typedef struct SlabBlockData *SlabBlock; /* forward reference */
>>>>> +typedef struct SlabChunkData *SlabChunk;
>>>>>
>>>>> Can we please not continue hiding pointers behind typedefs? It's a bad
>>>>> pattern, and that it's fairly widely used isn't a good excuse to
>>>>> introduce further usages of it.
>>>>>
>>>>
>>>> Why is it a bad pattern?
>>>
>>> It hides what is passed by reference, and what by value, and it makes it
>>> a guessing game whether you need -> or . since you don't know whether
>>> it's a pointer or the actual object. All to save a * in parameter and
>>> variable declaration?...
>>>
>>
>> FWIW I don't like that pattern either although it's used in many
>> parts of our code-base.
>
> But relatively few new ones, most of it is pretty old.
>
I do agree it's not particularly pretty pattern, but in this case it's
fairly isolated in the mmgr sources, and I quite value the consistency
in this part of the code (i.e. that aset.c, slab.c and generation.c all
use the same approach). So I haven't changed this.
The attached v7 fixes the off-by-one error in slab.c, causing failures
in test_decoding isolation tests, and renames Gen to Generation, as
proposed by Petr.
regards
Tomas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackersAttachments:
[application/x-compressed-tar] slab-allocators-v7.tgz (19.0K, ../40888631-2761-6eaa-e76f-3fdf7a09bd03@2ndquadrant.com/2-slab-allocators-v7.tgz)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tomas.vondra@2ndquadrant.com, andres@anarazel.de, petr@2ndquadrant.com, robertmhaas@gmail.com, johngorman2@gmail.com
Subject: Re: PATCH: two slab-like memory allocators
In-Reply-To: <40888631-2761-6eaa-e76f-3fdf7a09bd03@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox