Re: [Tarantool-patches] [PATCH 2/2] fiber: destroy fiber.storage created by iproto

[Vladislav Shpilevoy <v.shpilevoy@tarantool.org>]

On 13/12/2019 08:58, Konstantin Osipov wrote:
> * Vladislav Shpilevoy <v.shpilevoy@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.