From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by dpdk.org (Postfix) with ESMTP id 2DF2DA56E for ; Fri, 8 Jul 2016 19:36:09 +0200 (CEST) Received: by mail-wm0-f48.google.com with SMTP id z126so19237507wme.0 for ; Fri, 08 Jul 2016 10:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=YaVh/expasF71fczZknYoDFCtpjxt5XxUq/Gs8CfNi0=; b=sGSRmKhuGtwojqC1+gIHovqv8Wbvgdvdun5RkIGPu/6Z6+eRrpQNAosQUpoLZROGCr cpVSMhb8PYf7UUwenTFk2llsppwuHCV7AyXtofSn2qadjn5K8/dPABJSc4gDQAF2U93W rhVPeFDs3YVfwoi2YxgNj982/sPi9zz724Xc4w+dmKa8apIkvg8ZdC8lSzkP6diM6o/w 9DHLu46H6c8oTVasaXgKxdNq0BQO/bx9oRTfuEcFxqG/7TJwfrhi33j/XhxsJifnsD3R 3kb/iZnG5AHHS4XULX89eFbUrvOJD4Cs0of7hh1NvVscw3120EB7YMkuj7ko01ahsK1c a+6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=YaVh/expasF71fczZknYoDFCtpjxt5XxUq/Gs8CfNi0=; b=UTueJ2ts0TfebUQU3CI3kcXhO9BRZy51PwySNZvTPo5EVTO0lZrN3he0BjBqowcwRv /xhWHv6t/fSSskO53C1R9si7ntaKeeigoK4rvY+7hS5amioIQUW5Z18Gksqcxh/OhcXK Dbu8/k3wCTJLk0Pv4YVbKGN3++jnbPBA2Veg19p1R5m8FjGQbFmIuVcDy4/gLwZLZWN0 eD6N4eo6hm4Apw0/tv9t8Mlhmz3iNHM/dKif5xyo9pDYsdFDvx5Lyy5mV/0MuSp/PKx1 r+8OgyqIe0PJfkLsYGWi6dQokAZnw89SdvbNerlq3fyEfehmvWpyo/07pQOdlVz88E0Y 6CdQ== X-Gm-Message-State: ALyK8tKovtvHzTS4xfpx8DTUKUuFzosV5WIGg5oAnwz+rdEbNtmksmYQ7disMIyFHsmCMEJn X-Received: by 10.194.70.41 with SMTP id j9mr6453297wju.30.1467999368790; Fri, 08 Jul 2016 10:36:08 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id i74sm4000119wmg.21.2016.07.08.10.36.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jul 2016 10:36:07 -0700 (PDT) From: Thomas Monjalon To: "Liang, Cunming" Cc: Matthew Hall , dev@dpdk.org Date: Fri, 08 Jul 2016 19:36:07 +0200 Message-ID: <7816883.NtLY7W8fN8@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <56F20C56.9050801@intel.com> References: <1455399524-3252-1-git-send-email-mhall@mhcomputing.net> <20160322073921.GA28285@mhcomputing.net> <56F20C56.9050801@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-dev, 1/3] rte_interrupts: add rte_eal_intr_exit to shut down IRQ thread X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 17:36:09 -0000 Cunming, what is the status of this patchset, please? 2016-03-23 11:24, Liang, Cunming: > Hi Mattew, > > Thank you for your time. > > On 3/22/2016 3:39 PM, Matthew Hall wrote: > > On Mon, Mar 21, 2016 at 03:58:44PM +0800, Liang, Cunming wrote: > >> the default termination handler > > I am not so experienced with this "default termination handler". Can someone > > clarify what it is so I could comment better about it? > For example, you're handling SIGINT. After finishing your necessary app > cleanup, then 'signal(SIGINT, SIG_DFL); raise(SIGINT);'. > The default signal handler can terminate the interrupt thread. > > > > >> If EINTR is caused by some non-term purpose signals, are you going > >> to exit the interrupt thread any way? > > We should discuss what makes sense here. I'm just trying to get some things > > working and finding EINTR was getting eaten and causing infinite looping. > SIGINT/SIGTERM causes EINTR return, while SIGUSR1 also can cause the > EINTR return. For the dedicated EAL interrupt thread, it won't be > expected to exit for all kinds of the cause. > On this view, I'm in favor of your patch which cancel the interrupt > thread, but don't directly return by the EINTR. > > > > >> Without setting 'PTHREAD_CREATE_DETACHED' won't cause the infinite > >> loop. However by using pthread_cancel to terminate the thread, > >> indeed it's necessary to set 'PTHREAD_CREATE_DETACHED'. > > My general understanding is that PTHREAD_CREATE_DETACHED should be used for > > any thread, which should not keep a process open by itself if it is executing, > > i.e. a "daemon thread". I believe the interrupt thread qualifies as such a > > thread if I have understood everything right (which is hard to promise when > > you only work in DPDK in spare time). > > > >> It looks like 'pthread_cancel' is the right way and I saw it > >> continue keeps current EINTR handling in EAL interrupt thread. > > It is one option. Depending what makes the most sense. > > > >> 1. Can you explain and add patch comments why default signal handler > >> is not good enough to terminate app. > > Yes if someone call tell me more about what it is so I can check it. > > > >> 2. I propose to add addition comments on rte_epoll_wait() API > >> description. For any signal, it causes an error return, user needs > >> to handle. > > Agreed. > > > >> 3. Will you do a favorite to add 'PTHREAD_CREATE_DETACHED' to all > >> EAL pthread too. > > As a spare time developer I am a bit conservative about too large of a scope > > and messing with code for other threads or features I didn't personally use or > > test. This is because I don't have the same QA resources as Intel / 6WIND / > > etc.. Some help from a full time developer would be great here. > All right, reasonable to me. > > > > >> Cunming > > Matthew. >