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 B148D2F686 for ; Mon, 3 Jun 2019 11:53:28 -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 b-wU-uNuLX3r for ; Mon, 3 Jun 2019 11:53:28 -0400 (EDT) Received: from smtp37.i.mail.ru (smtp37.i.mail.ru [94.100.177.97]) (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 6FFF82F660 for ; Mon, 3 Jun 2019 11:53:28 -0400 (EDT) Subject: [tarantool-patches] Re: [PATCH v2] core: Non-blocking io.popen References: <20190529070809.18962-1-szudin@tarantool.org> <20190531114943.2zurdo3m6rct3hzk@esperanza> <20190531173244.GG31572@atlas> From: Stanislav Zudin Message-ID: Date: Mon, 3 Jun 2019 18:53:23 +0300 MIME-Version: 1.0 In-Reply-To: <20190531173244.GG31572@atlas> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: tarantool-patches@freelists.org, Konstantin Osipov On 31.05.2019 20:32, Konstantin Osipov wrote: > * Vladimir Davydov [19/05/31 16:01]: >>> +static struct popen_data * >>> +popen_lookup_data_by_pid(pid_t pid) >>> +{ >>> + struct popen_data *cur = popen_data_list; >>> + for(; cur; cur = cur->next) { >>> + if (cur->pid == pid) >>> + return cur; >>> + } >> >> Please write a comment explaining why you think linear search is fine >> here and why we don't use some kind of hash or tree. > > If it is a list of all popen processes, please avoid. > We can't afford adding a yet another, even unlikely, reason for a > 100% hog. This makes support difficult - keeping them all one's > head and checking neither is triggered. > How many simultaneously running popen processes do you expect? I believe it's tens, not even hundreds. In this case the hash won't give any noticeable performance improvement in comparison with the list. The newly created process is being put in the head of the list. It's O(1). The O(N) occurred only in the SIGCHLD handler and in the finalizer.