From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <vdavydov.dev@gmail.com>
Date: Fri, 31 May 2019 20:49:52 +0300
From: Vladimir Davydov <vdavydov.dev@gmail.com>
Subject: Re: [tarantool-patches] Re: [PATCH v2] core: Non-blocking io.popen
Message-ID: <20190531174952.ws2phg77gaqrynad@esperanza>
References: <20190529070809.18962-1-szudin@tarantool.org>
 <20190531114943.2zurdo3m6rct3hzk@esperanza>
 <20190531173244.GG31572@atlas>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190531173244.GG31572@atlas>
To: Konstantin Osipov <kostja@tarantool.org>
Cc: tarantool-patches@freelists.org, Stanislav Zudin <szudin@tarantool.org>
List-ID: <tarantool-patches.dev.tarantool.org>

On Fri, May 31, 2019 at 08:32:44PM +0300, Konstantin Osipov wrote:
> * Vladimir Davydov <vdavydov.dev@gmail.com> [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.

OK, makes sense. We should probably use mhash then. It shouldn't be
difficult to do.