[Tarantool-patches] [PATCH 2/2] fiber: destroy fiber.storage created by iproto
Vladislav Shpilevoy
v.shpilevoy at tarantool.org
Sat Dec 14 02:11:54 MSK 2019
On 13/12/2019 08:58, Konstantin Osipov wrote:
> * Vladislav Shpilevoy <v.shpilevoy at tarantool.org> [19/12/13 09:42]:
>>> Can you move it to Lua fiber object and iproto_msg object?
>>
>> I am not sure I understand what you mean. I can't move lua fiber
>> storage destructor to iproto. I need Lua for that. So this should
>> be in Lua folder.
>
> I mean struct rlist on_request_end should be a member of
> iproto_msg, not struct fiber. Does it make sense?
>
>> If you are talking about moving trigger list to iproto and Lua,
>> and somehow saying pointer at that list to a member in struct
>> fiber, then
>
> No, why do you need to store the list in struct fiber?
>
Because the only thing which is available in lua/fiber.c is the
fiber object.
>> 1) I would need to patch C version too, because we have public
>> C API. The fact you forgot about C API says, that it is not
>> a good idea to make that cleanup in each front end. Easy to
>> miss something;
>
> C api will enter into Lua land (lbox_pushfiber) as soon as it
> creates a Lua fiber, and the Lua land will call the trigger in
> the end of lbox_fiber_run_f.
lbox_fiber_run_f is not called for C fibers. This is for Lua born
fibers only. To invoke a C function Lua is not used.
>> 2) That will give exactly the same - a member in struct fiber.
>> There just no other communication channel between different
>> frontends in which a fiber may participate during lifetime;
>
> Why do you think there will be different frontends involved? The
> storage is pure-Lua, there is no fiber storage for non-Lua fibers.
>
Because other frontends will appear.
>> 3) We would need to add a new member to struct fiber and
>> increase its size.
>
> Please see above, do you get the idea now?
>
>
No. I don't understand what you want and how.
More information about the Tarantool-patches
mailing list