From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 6745F7030F; Thu, 25 Feb 2021 01:39:23 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 6745F7030F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1614206363; bh=V+tF8XYyp7AxVKwVNeY7Z3VVNoOil0fBpKojKYjsjyI=; h=To:References:Date:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=p3eojrUvuOaBqgN7WoG+GdI9VAVSCCzwJ0ZEs0gPAatoJdH5XDql4xiIFLAA+Cjac xVgQawI8RT0HXt0yieRNKfaHApw9B+yjeIWO37glXrw2qImip8yWVt/VrGQRNcQ5yl N5xppgx2ZnvsfztI780xuctjndQibZ7DW3GTOJog= Received: from smtp53.i.mail.ru (smtp53.i.mail.ru [94.100.177.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id AA6D57030F for ; Thu, 25 Feb 2021 01:39:22 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org AA6D57030F Received: by smtp53.i.mail.ru with esmtpa (envelope-from ) id 1lF2oT-0000QU-3f; Thu, 25 Feb 2021 01:39:22 +0300 To: Cyrill Gorcunov References: <20210222182030.76232-1-gorcunov@gmail.com> <41811c65-448c-0de6-68cd-6a64779ca283@tarantool.org> <0482394d-1600-45ca-8b0e-d230d4dfa8fe@tarantool.org> Message-ID: <334c9ace-2e92-5b8b-f727-ac33f69a25d9@tarantool.org> Date: Wed, 24 Feb 2021 23:39:20 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD975C3EC174F5669221340953D8FEAAFCA26BB79E5C093AA91182A05F5380850406CAF0CD592BD02733671FF2E5977FF213CEC081F11E1C5ABD04D79ED3F03D54E X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7D8156D3FCB551F18EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637D7C7E03580C3DB018638F802B75D45FF5571747095F342E8C7A0BC55FA0FE5FCEF6CC647C0669FAF76CBE1470165BEFA3159CD21313BC673389733CBF5DBD5E913377AFFFEAFD269176DF2183F8FC7C0D9442B0B5983000E8941B15DA834481FCF19DD082D7633A0EF3E4896CB9E6436389733CBF5DBD5E9D5E8D9A59859A8B6AEEA5BB16A939343CC7F00164DA146DA6F5DAA56C3B73B237318B6A418E8EAB8D32BA5DBAC0009BE9E8FC8737B5C224997E8830C6FC0247476E601842F6C81A12EF20D2F80756B5F7E9C4E3C761E06A776E601842F6C81A127C277FBC8AE2E8BA55178B8B5B93CD43AA81AA40904B5D9DBF02ECDB25306B2B25CBF701D1BE8734AD6D5ED66289B5278DA827A17800CE7B2B7C64F398C741067F23339F89546C5A8DF7F3B2552694A6FED454B719173D6725E5C173C3A84C3DB8B71E42BA00C4F35872C767BF85DA2F004C906525384306FED454B719173D6462275124DF8B9C9AE7E30DF62CE24E4E5BFE6E7EFDEDCD789D4C264860C145E X-B7AD71C0: 14C14B24D00AF5AC321EF223B8115265C69B993890792DF82CDD5689AFBDA7A24A6D60772A99906F8E1CD14B953EB46DF31058C4B5160E69355D89D7DBCDD132 X-C1DE0DAB: 0D63561A33F958A5A59BFA7ACB17FE376533B9649E98EE2DC3FBB0ED4E8953D3D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75968C9853642EB7C3410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D344888A9AABCDD3225984E67568C82E4A193BE011031E021109ACB39BB45D9A709425DA6C022E2C9631D7E09C32AA3244C2D1DBB01026E6F04891DAD296CE498E31DD47778AE04E04DFACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojvz1c9SWJtj+9Kqg077omnA== X-Mailru-Sender: 504CC1E875BF3E7D9BC0E5172ADA311046BF50748817AA4D86ED74E4BDD5008E1068CCE1DAF2B76B07784C02288277CA03E0582D3806FB6A5317862B1921BA260ED6CFD6382C13A6112434F685709FCF0DA7A0AF5A3A8387 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH] say: fix format for fiber()->fid X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Vladislav Shpilevoy via Tarantool-patches Reply-To: Vladislav Shpilevoy Cc: tml Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On 24.02.2021 09:28, Cyrill Gorcunov wrote: > On Tue, Feb 23, 2021 at 11:47:44PM +0100, Vladislav Shpilevoy wrote: >>>>> diff --git a/src/lib/core/say.c b/src/lib/core/say.c >>>>> index cbd10e107..6138752a7 100644 >>>>> --- a/src/lib/core/say.c >>>>> +++ b/src/lib/core/say.c >>>>> @@ -792,7 +792,7 @@ say_format_plain_tail(char *buf, int len, int level, const char *filename, >>>>> if (cord) { >>>>> SNPRINT(total, snprintf, buf, len, " %s", cord->name); >>>>> if (fiber() && fiber()->fid != FIBER_ID_SCHED) { >>>>> - SNPRINT(total, snprintf, buf, len, "/%i/%s", >>>>> + SNPRINT(total, snprintf, buf, len, "/%u/%s", >>>>> fiber()->fid, fiber_name(fiber())); >>>> >>>> I remember we had some issues about %u not being compatible with uint32_t so >>>> we did manual casts to 'unsigned'. Not sure though what was the commit/ticket, >>>> or if it really happened. >>> >>> I suspect you rather mean uint64_t, which indeed better convert to >>> excplicit "long long". >> >> No, I mean exactly uint32_t. You don't have a guarantee that it is >> the same as 'unsigned' AFAIK. > > It is, on x86. In the close future we will build on the new ARM Macs. Simply because many of our developers use Macs and they want the new models. All our assumptions about x86 being the only platform should not be made anymore. >>> Strictly speaking if we really need to cover >>> compatibility we would _had_ to use PRIx macros which are so ugly :/ >> >> This is why I want us to use casts to 'unsigned' when we use %u. They >> are less ugly. > > We will have to cover a bunch of already existing code for nothing :( > But OK, I'll add explicit cast. It is ok to keep the old code intact where the compiler won't give any errors when you enable the compile time checking. >> After more consideration I also realized we should not use uint32_t >> for fiber ids. It is monotonically growing. Which means it will overflow >> in the foreseeable future on a long-running instance. > > - it is explected to be overlowable from the beginning Why? It is not safe. There is no any protection in case of overflow and ids clash. > - the IDs are recycled Exactly. They start recycle on overflow. This means if you had a long living fiber for 50 days, and the scenario described by me happens, you will get id clash. > I've been talking to Kostya about a year ago once I discovered that > we're walking in cycle when reusing IDs. He assured me that this is > fine and to get a problem we have to allocate 4294967195 fibers at > once which will require ~1.5T of memory just to allocate fiber structure. It is not about at once. It is about long running instances. > Hardy to happen. Still I think we at least should add a painc in case of > hash collision for future. We should just make it int64_t and forget about it IMO. >> - Use 64bit ids for fibers. Unless I am wrong somewhere in my thoughts >> above. > > This is dubious. Personally I would prefer to have them as uint64_t too > now and for all, to simply forget about this potential issue. +4 bytes > to fiber structure seems to be acceptable trade off. Exactly.