From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) (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 97DED469719 for ; Tue, 3 Nov 2020 10:26:19 +0300 (MSK) Received: by mail-lf1-f50.google.com with SMTP id h6so20840510lfj.3 for ; Mon, 02 Nov 2020 23:26:19 -0800 (PST) Date: Tue, 3 Nov 2020 10:26:16 +0300 From: Cyrill Gorcunov Message-ID: <20201103072616.GH2339@grain> References: <20201014133535.224573-1-gorcunov@gmail.com> <20201014133535.224573-4-gorcunov@gmail.com> <6572e8c8-b801-0db9-80c0-31bdaca89355@tarantool.org> <20201030125101.GF198833@grain> <7a6a6dd8-5eb0-0c55-2eeb-8aac3f5b11bd@tarantool.org> <20201031215946.GI198833@grain> <05fd82cd-e8d1-c496-2bdb-3a6b2b075fab@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <05fd82cd-e8d1-c496-2bdb-3a6b2b075fab@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v8 3/4] box/cbox: implement cbox Lua module List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tml On Mon, Nov 02, 2020 at 11:25:53PM +0100, Vladislav Shpilevoy wrote: ... > > > > Vlad, frankly I don't understand what else we can put here in documentation, > > lets talk f2f about this. > > Давай на русском. > > Не понимаю. Как это нечего положить в доку? У тебя С функции > возвращают всегда не то, что юзер из них вернул. Ты добавляешь туда > true, или nil,err. Как до этого юзер догадается, что функция > при вызове через cbox модифицирует набор возвращаемых значений? Луа > так не делает, поэтому ты не можешь сказать, что оно работает как > Луа. ... > > Это не точно как луа, и явно должно быть в документации. Thanks a huge, Vlad! Now I see what you mean. > Ошибки тоже надо задокументировать - что функции cbox никогда не > кидают исключения. Только возвращают nil, err. +1 > > По поводу бенчей - да, походу дерево выглядит лучше или по крайней > мере предсказуемо. Мне норм оставить дерево. По хешу я создал тикет, > так как оставлять это без действия нельзя. Если текущий хеш так > плох, его надо поменять. Либо его метод расчета, либо вообще на > дерево его заменить в некоторых других местах тоже. Но я все еще не > уверен, что твои данные для "худшего случая" вообще возможны в > реальности, на типичных именах функций, например. Так что это надо > еще до-проверять. > > https://github.com/tarantool/tarantool/issues/5492 Я эту багу себе взял. И да "худший случай" что я привел -- он синтетический. Я специально использовал генератор коллизий, поэтому хэш настолько просел. В нормальных условиях конечно не будет такого потока коллизий. В любом случае xxhash выглядит лучше, так что посмотрим повнимательней. > >>>> 9. We already discussed it a ton of times, literally exactly the > >>>> same 'problem' with struct error objects. A 64 bit integer > >>>> will not overflow for your lifetime even if it would increment > >>>> every nanosecond. How is it possible? Why the code should get > >>>> complicated by making a simple 'ref' function be able to fail? > >>> > >>> This has nothing to do for fair use. It prevents from errors where > >>> you occasionally screwed the counter. > >> > >> In the code you always either increment or decrement it. How many > >> lifes you will need to get it 'screwed'? > > > > Counters are not always screwed by correct calls of inc/dec but sometime > > it might be an indirrect errors due to addressing bugs and such. IOW > > if we can check counters for saturation -- we should. If you really > > think it has such big penalty we could put it under #ifdef. > > Это будет еще хуже с ifdef. Все равно придется проверять, что ref не > вернул -1, что выглядит супер стремно. We could wrap it with inline but thnking more I guess we can simply drop this all saturation idea for now. Let forget. > >>> What we really > >>> need is a general kind of kref_t and it *must* include saturation > >>> check somewhere inside and panic on overflow. > >> > >> This is not really applicable in Tarantool. At least not everywhere. > >> Struct tuple, for instance, is referenced, but it uses a very special > >> reference counter to save every single byte, because tuple count is > >> millions and billions. > > > > And I don't propose it for bigrefs but IIRC we've a number of places > > where plain reference counters are used? > > Таких мест точно не много, но да, есть структуры, которые рефаются > обычными интами. Все из-за того, что рефы очень не нравились Косте, > и их супер мало применяли. Я не найду сходу сейчас. OK