From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gorcunov@gmail.com>
Received: from mail-lf1-f67.google.com (mail-lf1-f67.google.com
 [209.85.167.67])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id D3408469719
 for <tarantool-patches@dev.tarantool.org>;
 Sat, 14 Mar 2020 22:48:41 +0300 (MSK)
Received: by mail-lf1-f67.google.com with SMTP id j17so10668482lfe.7
 for <tarantool-patches@dev.tarantool.org>;
 Sat, 14 Mar 2020 12:48:41 -0700 (PDT)
Date: Sat, 14 Mar 2020 22:48:37 +0300
From: Cyrill Gorcunov <gorcunov@gmail.com>
Message-ID: <20200314194837.GX27301@uranus>
References: <3d2907a0285c640ea09eec86c8922e43c5844953.1584198310.git.v.shpilevoy@tarantool.org>
 <20200314163432.GW27301@uranus>
 <5b4578df-aab3-968b-f9bd-a00b60bd6591@tarantool.org>
 <86521117-2757-a564-a9ab-5c36041dca40@tarantool.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <86521117-2757-a564-a9ab-5c36041dca40@tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH 1/1] fiber: extend max fiber name
 length to 255
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org

On Sat, Mar 14, 2020 at 06:32:01PM +0100, Vladislav Shpilevoy wrote:
> Besides, most of the users don't use long names. So for them
> it would be overkill to allocate such a big name memory for each
> fiber.

Look, currently all fiber data (including name) placed in one
continious memory area. After the patch the name gonna be "somewhere",
moreover this "somewhere" is completely unpredictable and access
to it will cause (i'm pretty sure) useless cache drains. If we
really need to support long names then we better make some union
which would carry both, short 32 byte names or long dynamically
allocated names.

And no, the statement "heap allocation doesn't affect anyone"
is simply wrong, this is not how memory works on a low level
(otherwise we wouldn't use "small" helpers at all, plain libc
malloc would fit us without a problem :).