Tarantool development patches archive
 help / color / mirror / Atom feed
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 

  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