From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> To: Konstantin Osipov <kostja.osipov@gmail.com>, tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH 2/2] fiber: destroy fiber.storage created by iproto Date: Fri, 13 Dec 2019 01:02:31 +0100 [thread overview] Message-ID: <96368326-84a1-0b3c-15f8-54e3d044db85@tarantool.org> (raw) In-Reply-To: <20191212084603.GA24448@atlas> Hi! Thanks for the review! On 12/12/2019 09:46, Konstantin Osipov wrote: > * Vladislav Shpilevoy <v.shpilevoy@tarantool.org> [19/12/12 00:27]: >> - I moved cleanup to iproto.cc, and called it tx_fiber_cleanup(). >> By analogue with tx_fiber_init() which currently initializes the >> fiber; >> >> - I made cleanup triggers always clean them by themselves to remove >> trigger_destroy() from fiber.c. >> >> But it didn't help me to understand, why are you saying, that >> tx and session should not use these triggers. Tx, in case it was >> not removed from fiber before its cleanup, should be destroyed. >> Session uses that trigger to destroy local one-fiber sessions, >> which die together with the fiber getting recycled/killed. So >> what is a problem? That trigger perfectly fits all the needs. > > OK, the function itself may be a match, but it doesn't make the > idea of using the same trigger object for everything right, don't > you think? For everything possible to imagine - no. For txn, session, and language specific fiber-local data - yes. And by coincidence that is pretty much everything we have now. > > My point is that you do not only move where the function is > invoked, but also where the trigger list object is stored. Nope. The trigger list is still in struct fiber. > > 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. 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 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; 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; 3) We would need to add a new member to struct fiber and increase its size. > There could be no other entry points to the request, so my point > is that the trigger is part of request state, not fiber state. 'Request' idea is different for session, for txn, for iproto. You can't define one request for all things. While you are trying to define a 'request' concept, there is an already defined concept of fiber function. The function which a fiber executes. That should be the anchor. This is the 'request' in terms of fibers. Fiber owns session, fiber owns txn, fiber owns Lua resources. So it is his task to clean them up. And it should be in his triggers. On_cleanup is fiber's destructor. Yes, fiber can hand out these resources, but all access to them goes through fiber object. Fiber owns them, and fiber should destroy them when its current task is done. This is fiber's responsibility. > > Does it make any sense? >
next prev parent reply other threads:[~2019-12-13 0:02 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-08 19:28 [Tarantool-patches] [PATCH 0/2] Fiber storage leak Vladislav Shpilevoy 2019-12-08 19:28 ` [Tarantool-patches] [PATCH 1/2] fiber: unref fiber.storage via global Lua state Vladislav Shpilevoy 2019-12-11 23:57 ` Igor Munkin 2019-12-12 8:50 ` Konstantin Osipov 2019-12-12 23:38 ` Vladislav Shpilevoy 2019-12-13 10:44 ` Igor Munkin 2019-12-08 19:28 ` [Tarantool-patches] [PATCH 2/2] fiber: destroy fiber.storage created by iproto Vladislav Shpilevoy 2019-12-09 7:21 ` Konstantin Osipov 2019-12-09 23:31 ` Vladislav Shpilevoy 2019-12-10 8:21 ` Konstantin Osipov 2019-12-10 8:32 ` Konstantin Osipov 2019-12-10 22:59 ` Vladislav Shpilevoy 2019-12-11 7:08 ` Konstantin Osipov 2019-12-11 21:23 ` Vladislav Shpilevoy 2019-12-12 0:00 ` Igor Munkin 2019-12-12 23:37 ` Vladislav Shpilevoy 2019-12-13 13:35 ` Igor Munkin 2019-12-12 8:46 ` Konstantin Osipov 2019-12-13 0:02 ` Vladislav Shpilevoy [this message] 2019-12-13 7:58 ` Konstantin Osipov 2019-12-13 23:11 ` Vladislav Shpilevoy 2019-12-14 12:26 ` Konstantin Osipov 2019-12-14 12:30 ` Konstantin Osipov 2019-12-14 12:33 ` Konstantin Osipov 2019-12-14 16:49 ` Vladislav Shpilevoy 2019-12-14 20:59 ` Vladislav Shpilevoy
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=96368326-84a1-0b3c-15f8-54e3d044db85@tarantool.org \ --to=v.shpilevoy@tarantool.org \ --cc=kostja.osipov@gmail.com \ --cc=tarantool-patches@dev.tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH 2/2] fiber: destroy fiber.storage created by iproto' \ /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