[Tarantool-patches] [PATCH v8 3/4] box/cbox: implement cbox Lua module

[Cyrill Gorcunov]

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