From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8D099A0546; Fri, 30 Apr 2021 19:22:54 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 08B314014F; Fri, 30 Apr 2021 19:22:54 +0200 (CEST) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by mails.dpdk.org (Postfix) with ESMTP id 5F6A24013F for ; Fri, 30 Apr 2021 19:22:53 +0200 (CEST) Received: by mail-lj1-f181.google.com with SMTP id d15so30461296ljo.12 for ; Fri, 30 Apr 2021 10:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=CQMybWd0OZSijMYRhhVj516Gdww4PBU742coa/XQpHk=; b=nu73v5HF7G4SeYyrBeka4q7K+eOQmP8rB/jnOSV94Ba76iTyPcikYN2xIcRjSJvvXV gft6h3oi2Sjz48QTMikeUA7jRd6txiMQ/z9OKaEbKrvPltjbPp/SPrMavkQjYrwNP2aX u8abFP9kRPNVnhZJVkcw4d5mawre2JgL52z/VXF1o3mxbR3K/5E4zzxDoSOAv2EnLipB hXa+N8tCsurgAiLbqtNCoJuaQieOvjf8uq0xdwbo/ieUAxtwwj0s/pofYv64fSMzwjfc mE8J22ZsWabl9+7KotYiEyRH6rBd7ALPKWTDcMhw7YHnNajysSj/N6nDzGoJ64b/Iul7 AA2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=CQMybWd0OZSijMYRhhVj516Gdww4PBU742coa/XQpHk=; b=KXsareWXQTmS+EpB8vBBXPxphtCCNUolziOTg6Cq7v9SwLNOM4rOYFsBARdUiWJk09 KJ/xHm/NuM0cIbu/RLbrtnlDg6iA6EqCOtKHqqE0BpqmNPz1X2ODMZ8Pj1CPpvB8vlmM UtWUkZGGlIM7gmYVMYo6FygL89wiuPkuUYRQF2Js7AKGZf6xuPHfYAtL697VP1ZZnApa F4cLxVhVmyQGsDXTjsEPjlL/A8TavOawEjj4eYJ12FXGMGb05dEWk1Hjd8B1uljK1Aq7 CEf9eB1brtECcoRVU9sRlHpMfqkZdgXXjiMMSqK42IBzLN9kjQsmuJk5f3EjxCirBfM7 wssg== X-Gm-Message-State: AOAM533eUed0gwAPGZUWL9EIswjQ7zg11s1v+tLZfA3AZwmNTRk1VE8h 9D1TV6/Pii/j98oRoz1wyLI= X-Google-Smtp-Source: ABdhPJysnIA+yq/LHuEKEZi7hIzEpr60xje6Po1sAMaXc8XUG6nsqP44/RptdSeNQnMYgcnOsNB1wA== X-Received: by 2002:a2e:a28f:: with SMTP id k15mr4428261lja.163.1619803372976; Fri, 30 Apr 2021 10:22:52 -0700 (PDT) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id l8sm294746lja.35.2021.04.30.10.22.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Apr 2021 10:22:51 -0700 (PDT) Date: Fri, 30 Apr 2021 20:22:50 +0300 From: Dmitry Kozlyuk To: Dmitry Malloy Cc: Narcisa Ana Maria Vasile , "dev@dpdk.org" , thomas , Khoa To , Narcisa Ana Maria Vasile , Tyler Retzlaff , "talshn@nvidia.com" , Omar Cardona , "bruce.richardson@intel.com" , "david.marchand@redhat.com" , "Kadam, Pallavi" Message-ID: <20210430202250.7c91da09@sovereign> In-Reply-To: References: <1617057640-24301-2-git-send-email-navasile@linux.microsoft.com> <1617413948-10504-1-git-send-email-navasile@linux.microsoft.com> <1617413948-10504-7-git-send-email-navasile@linux.microsoft.com> <20210429234414.73ce39d7@sovereign> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [EXTERNAL] Re: [PATCH v6 06/10] eal: add thread lifetime management X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2021-04-29 21:31 (UTC+0000), Dmitry Malloy: > Thread cancellation is a pain point. Emulating it properly is nearly > impossible (without hooking into various OS calls which are supposed to be > "cancellation points"). I do like the cancellation token idea, but I'm not > sure how existing clients, who rely on existing phtread_cancel() semantic, > will react to that - it will require a code re-write. > > How about we defer fixing this to another follow-up change? I'm strictly against accepting code with known severe bugs. Alternative: 1. Don't add rte_thread_cancel() in public API. 2. Implement rte_thread_cancel() as internal API with cancellation tokens. 3. Rewrite DPDK code to use rte_thread_cancel(). 4. For external users: 4.1. If their app is using pthread, they can use pthread backend for DPDK and call pthread_cancel() directly. 4.2. If their app is not designed for pthread, they probably don't need pthread_cancel() semantics and cancel threads another way. 4.3. If it's a brand new app, they will only use public API. In 4.1 users need a pthread_t. In principle, they can call pthread_self() from the thread to be cancelled and pass it to the thread that cancels. Or we could provide API to get backend type and native handle. Since users have to rewrite their code anyway to move from pthread to rte_thread, I'm for the former approach. "Escape hatch" API would be very fragile. P.S. Please avoid top-posting.