From: Konstantin Osipov <kostja.osipov@gmail.com> To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH 2/2] fiber: destroy fiber.storage created by iproto Date: Tue, 10 Dec 2019 11:32:58 +0300 [thread overview] Message-ID: <20191210083258.GD21413@atlas> (raw) In-Reply-To: <a5844a06bb9d4046bd8d01bf11c94ce2c8adc775.1575833120.git.v.shpilevoy@tarantool.org> * Vladislav Shpilevoy <v.shpilevoy@tarantool.org> [19/12/08 23:47]: > static int > -session_on_stop(struct trigger *trigger, void * /* event */) > +session_on_fiber_cleanup(struct trigger *trigger, void * /* event */) Please come up with a better name, and provide a comment. > - trigger_add(&fiber()->on_stop, &s->fiber_on_stop); > + trigger_create(&s->fiber_on_cleanup, session_on_fiber_cleanup, > + NULL, NULL); > + /* Add a trigger to destroy session on fiber cleanup. */ > + trigger_add(&fiber()->on_cleanup, &s->fiber_on_cleanup); I don't understand why these two concerns are intermixed here. Why is this code part of session now? I think if you change the semantics of the trigger, you should move setting/resetting it to the place which controls the relevant object and its life cycle. Specifically, if you change fiber.storage semantics to be per-request *or* per Lua fiber, you should move the trigger to lua fiber create/destroy + iproto request processing start/end. Instead you move it to the core library, which is oblivious of these events. The way the core is implemented may change, and whoever is changing it will have to be aware of the legacy behaviour you make it depend on. > index eff3d7a67..710e4919b 100644 > --- a/src/box/session.h > +++ b/src/box/session.h > @@ -103,8 +103,11 @@ struct session { > union session_meta meta; > /** Session user id and global grants */ > struct credentials credentials; > - /** Trigger for fiber on_stop to cleanup created on-demand session */ > - struct trigger fiber_on_stop; > + /** > + * Trigger for fiber on_cleanup to cleanup created > + * on-demand session. > + */ > + struct trigger fiber_on_cleanup; ... > - trigger_clear(&txn->fiber_on_stop); > + trigger_clear(&txn->fiber_on_cleanup); Please see the above comment. Fiber cleanup trigger, as defined now, does not have anything to do with the session, or fiber, or transaction. It belongs to the request processing layer and should be set/cleared from it. > - struct rlist on_stop; > + /** > + * Triggers invoked before this fiber is > + * stopped/reset/recycled/destroyed/reused. In other > + * words, each time when the fiber has finished execution > + * of a request. > + */ > + struct rlist on_cleanup; Please make the comment describing the timing when this trigger is called less broad and more accurate, calling out the specific places when the trigger is called, and call the trigger accordingly. on_request_or_fiber_end? > +/** Invoke cleanup triggers and delete them. */ > +void > +fiber_cleanup(struct fiber *f); The call for a better name for the event and the accompanying action applies to all of the new api methods this patch introduces. > cmsg_deliver(msg); > + /* > + * Different messages = different requests. They > + * should not affect each other. This is why > + * cleanup is done here. > + */ > + fiber_cleanup(f); Ugh. I think this is a layering violation, and the cleanup call should be somewhere inside cmsg_deliver for the relevant messages. The rlist with cleanup triggers is better stored in a fiber key. -- Konstantin Osipov, Moscow, Russia
next prev parent reply other threads:[~2019-12-10 8:33 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 [this message] 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 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=20191210083258.GD21413@atlas \ --to=kostja.osipov@gmail.com \ --cc=tarantool-patches@dev.tarantool.org \ --cc=v.shpilevoy@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