From mboxrd@z Thu Jan  1 00:00:00 1970
From: Olivier Matz <olivier.matz@6wind.com>
Subject: Re: [PATCH v2 3/4] eal: set name when creating a control
	thread
Date: Mon, 23 Apr 2018 14:49:09 +0200
Message-ID: <20180411112943.7ez3rv2jnqvdg24x@platinum>
References: <20180403130439.11151-1-olivier.matz@6wind.com>
 <20180403130439.11151-4-olivier.matz@6wind.com>
 <cb8a9072-455a-8b34-7413-532451eb782c@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: dev@dpdk.org
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67])
 by dpdk.org (Postfix) with ESMTP id 3D73C569B
 for <dev@dpdk.org>; Mon, 23 Apr 2018 14:49:16 +0200 (CEST)
Content-Disposition: inline
In-Reply-To: <cb8a9072-455a-8b34-7413-532451eb782c@intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Tue, Apr 10, 2018 at 05:34:36PM +0100, Burakov, Anatoly wrote:
> On 03-Apr-18 2:04 PM, Olivier Matz wrote:
> > To avoid code duplication, add a parameter to rte_ctrl_thread_create()
> > to specify the name of the thread.
> > 
> > This requires to add a wrapper for the thread start routine in
> > rte_thread_init(), which will first wait that the thread is configured.
> > 
> > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> > ---
> 
> <...>
> 
> > +
> > +	pthread_barrier_wait(&params.configured);
> > +
> > +	return 0;
> > +
> > +fail:
> > +	pthread_kill(*thread, SIGTERM);
> 
> This may be wrong, but perhaps instead of killing the thread outright, a
> better approach would be pthread_cancel? I'm always uneasy about mixing
> signals and pthreads...

Indeed, pthread_cancel() seems to be a better approach. I'll update the
patchset.

Thanks for the review.