From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> To: tarantool-patches@freelists.org, Konstantin Osipov <kostja@tarantool.org> Subject: [tarantool-patches] Re: [PATCH 1/1] core: introduce tt_static_sized_buf() Date: Sun, 28 Apr 2019 19:56:33 +0300 [thread overview] Message-ID: <0f812547-b60b-7927-7a27-f79a3fbe5b95@tarantool.org> (raw) In-Reply-To: <20190427211803.GC5662@atlas> On 28/04/2019 00:18, Konstantin Osipov wrote: > * Vladislav Shpilevoy <v.shpilevoy@tarantool.org> [19/04/27 15:39]: > > To solve your particular problem, you could simply increase the > static buffer size. This is a one-line patch. I suggest you do it > in scope of swim and be done with it. > > Here is why: > > Essentially, you introduce a new allocator. A very useful one, > indeed, but the protocol should follow one of an allocator, e.g. > provide alloc, realloc, and a (no-op) free. The allocator itself > should be moved to small/. You should check boundary conditions - > e.g. attempt to allocate more memory than the maximal size of the > static array - and return 0. tt_static_buf() then can be replaced > with static_alloc(desired size). > > If you wish to do all of the above in a separate patch - you're > more than welcome. I did, see the new mail thread. But I did not realloc() nor free(). Realloc() just is not needed. Free() would cause too huge changes in the code, because every single tt_sprintf and tt_static_buf would require free() - it would be tremendous diff. > > > -- > Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 >
prev parent reply other threads:[~2019-04-28 16:56 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-26 21:44 [tarantool-patches] " Vladislav Shpilevoy 2019-04-27 21:18 ` [tarantool-patches] " Konstantin Osipov 2019-04-28 16:56 ` Vladislav Shpilevoy [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=0f812547-b60b-7927-7a27-f79a3fbe5b95@tarantool.org \ --to=v.shpilevoy@tarantool.org \ --cc=kostja@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='[tarantool-patches] Re: [PATCH 1/1] core: introduce tt_static_sized_buf()' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox