From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sat, 29 Sep 2018 14:44:01 +0300 From: Vladimir Davydov Subject: Re: [tarantool-patches] Re: [PATCH v2 05/11] vinyl: implement quota wait queue without fiber_cond Message-ID: <20180929114401.375exjjkxuasznms@esperanza> References: <2144ee719cddf90f43389ebfb9979a2b4c5ee478.1538155645.git.vdavydov.dev@gmail.com> <20180929050531.GI32712@chai> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180929050531.GI32712@chai> To: Konstantin Osipov Cc: tarantool-patches@freelists.org List-ID: On Sat, Sep 29, 2018 at 08:05:31AM +0300, Konstantin Osipov wrote: > * Vladimir Davydov [18/09/28 21:00]: > > Using fiber_cond as a wait queue isn't very convenient, because: > > - It doesn't allow us to put a spuriously woken up fiber back to the > > same position in the queue where it was, thus violating fairness. > > - It doesn't allow us to check whether we actually need to wake up a > > fiber or it will have to go back to sleep anyway as it needs more > > memory than currently available. > > - It doesn't allow us to implement a multi-queue approach where fibers > > that have different priorities are put to different queues. > > > > So let's rewrite the wait queue with plain rlist and fiber_yield. > > Maybe you could factor out this change into an abstraction in fiber.[hc]? > Or fix fiber_cond to be fair? I don't see any point in abstracting such a tiny and simple thing as a wait queue, at least not right now, when we need it only in vy_quota. Note, what we need in vy_quota isn't as simple as waking up fibers in the order they were put to sleep, because we don't want to wake up a fiber if it will have to go back to sleep immediately. Besides, take a look at the last patch in the series where I turn the queue into a multi-queue in order to introduce quota consumer priorities. I don't rule out that it may be possible to make this code abstract, but IMO it isn't worth the effort right now.