From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 24 Apr 2018 16:05:51 +0300 From: Vladimir Davydov Subject: Re: [tarantool-patches] Re: [PATCH 6/8] netbox: introduce fiber-async API Message-ID: <20180424123902.vjw3wmz4xa3lu264@esperanza> References: <49a50d32a154959aa786ec2a85a4f74792d7ae09.1523903144.git.v.shpilevoy@tarantool.org> <20180423164450.yd7o7deawhjxbt7f@esperanza> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: To: Vladislav Shpilevoy Cc: tarantool-patches@freelists.org List-ID: On Mon, Apr 23, 2018 at 09:59:29PM +0300, Vladislav Shpilevoy wrote: > Hello. Thanks for review! > > On 23/04/2018 19:44, Vladimir Davydov wrote: > > On Mon, Apr 16, 2018 at 09:39:16PM +0300, Vladislav Shpilevoy wrote: > > > Now any netbox call blocks a caller-fiber until a result is read > > > from a socket, or time is out. To use it asynchronously it is > > > necessary to create a fiber per request. Sometimes it is > > > unwanted - for example if RPS is very high (for example, about > > > 100k), and latency is about 1 second. Or when it is neccessary > > > to send multiple requests in paralles and then collect responses > > > (map-reduce). > > > > > > The patch introduces a new option for all netbox requests: > > > is_async. With this option any called netbox method returns > > > immediately (but still yields for a moment) a 'future' object. > > > > > > By a future object a user can check if the request is finalized, > > > get a result or error, wait for a timeout, discard a response. > > > > > > Example of is_async usage: > > > future = conn:call(func, {params}, {..., is_async = true}) > > > -- Do some work ... > > > if not future.is_ready() then > > > result, err = future:wait_result(timeout) > > > end > > > -- Or: > > > result, error = future:result() > > > > > > A future:result() and :wait_result() returns either an error or > > > a response in the same format, as the sync versions of the called > > > methods. > > > > > > Part of #3107 > > > + -- It is possible that multiple fibers are waiting for > > > + -- a result. In such a case a first, who got it, must > > > + -- wakeup the previous waiting client. This one wakes > > > + -- up another. Another wakes up third one, etc. > > > + wakeup_client(old_client) > > > > This is rather difficult for understanding IMO. Can we use a fiber.cond > > instead? > > Sure, we can. Done on the branch. Thanks. The patch looks good to me now.