From: Cyrill Gorcunov <gorcunov@gmail.com> To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Cc: tml <tarantool-patches@dev.tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v8 3/4] box/cbox: implement cbox Lua module Date: Tue, 3 Nov 2020 10:26:16 +0300 [thread overview] Message-ID: <20201103072616.GH2339@grain> (raw) In-Reply-To: <05fd82cd-e8d1-c496-2bdb-3a6b2b075fab@tarantool.org> 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
next prev parent reply other threads:[~2020-11-03 7:26 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-14 13:35 [Tarantool-patches] [PATCH v8 0/4] box/cbox: implement cfunc " Cyrill Gorcunov 2020-10-14 13:35 ` [Tarantool-patches] [PATCH v8 1/4] box/func: factor out c function entry structure Cyrill Gorcunov 2020-10-29 22:15 ` Vladislav Shpilevoy 2020-10-30 9:51 ` Cyrill Gorcunov 2020-10-31 0:13 ` Vladislav Shpilevoy 2020-10-31 15:27 ` Cyrill Gorcunov 2020-10-14 13:35 ` [Tarantool-patches] [PATCH v8 2/4] module_cache: move module handling into own subsystem Cyrill Gorcunov 2020-10-29 22:15 ` Vladislav Shpilevoy 2020-10-30 10:15 ` Cyrill Gorcunov 2020-10-31 0:15 ` Vladislav Shpilevoy 2020-10-31 15:29 ` Cyrill Gorcunov 2020-10-14 13:35 ` [Tarantool-patches] [PATCH v8 3/4] box/cbox: implement cbox Lua module Cyrill Gorcunov 2020-10-29 22:15 ` Vladislav Shpilevoy 2020-10-30 12:51 ` Cyrill Gorcunov 2020-10-31 0:21 ` Vladislav Shpilevoy 2020-10-31 21:59 ` Cyrill Gorcunov 2020-11-01 8:26 ` Cyrill Gorcunov 2020-11-02 22:25 ` Vladislav Shpilevoy 2020-11-03 7:26 ` Cyrill Gorcunov [this message] 2020-11-12 22:54 ` Vladislav Shpilevoy 2020-11-13 18:30 ` Cyrill Gorcunov 2020-10-14 13:35 ` [Tarantool-patches] [PATCH v8 4/4] test: box/cfunc -- add simple module test Cyrill Gorcunov
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=20201103072616.GH2339@grain \ --to=gorcunov@gmail.com \ --cc=tarantool-patches@dev.tarantool.org \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH v8 3/4] box/cbox: implement cbox Lua module' \ /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