From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 3A3D822B06 for ; Mon, 8 Jul 2019 04:25:25 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCWVNNchen2m for ; Mon, 8 Jul 2019 04:25:25 -0400 (EDT) Received: from smtp5.mail.ru (smtp5.mail.ru [94.100.179.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id EDC65226A1 for ; Mon, 8 Jul 2019 04:25:24 -0400 (EDT) Date: Mon, 8 Jul 2019 11:25:21 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH 1/2] swim: pool IO tasks Message-ID: <20190708082521.GB24939@atlas> References: <20190705230136.GD30966@atlas> <609c7e7b-d8f7-413b-752c-94034bfd689b@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <609c7e7b-d8f7-413b-752c-94034bfd689b@tarantool.org> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: Vladislav Shpilevoy Cc: tarantool-patches@freelists.org * Vladislav Shpilevoy [19/07/07 16:28]: > >> +static struct stailq swim_task_pool; > >> +/** Number of pooled tasks. */ > >> +static int swim_task_pool_size = 0; > > > > These should be thread-local. > > Why? SWIM works in one thread, these values are never accessed > from another one. They would be just copied for each thread and > unused in all but one. What happens if I create multiple instances of swim library in multiple threads? These instances will try to concurrently access these members without mutexes. > > > > > Why not use mempool? > > > > > > Because 1) it is an overkill, 2) I don't want to depend on > slab allocator, 3) it just does not fit this case, according > to mempool description from mempool.h: > > "Good for allocating tons of small objects of the same size.". It is also quite decent for allocating many fairly large objects. The key point is that the object is of the same size. You can set up mempool the right slab size, and in this case it will do exactly what you want. -- Konstantin Osipov, Moscow, Russia