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 A33B346223 for ; Fri, 14 Feb 2025 10:23:33 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 228914064A; Fri, 14 Feb 2025 10:23:33 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) by mails.dpdk.org (Postfix) with ESMTP id 658CC40263 for ; Fri, 14 Feb 2025 10:23:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1739525012; x=1771061012; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=MpRvZTHXtZ4GO4Pi8WwTmY5hQbnXmwy2rjvvkBrCHlo=; b=DlUmIPk+wPMoSVtkpxp5fCAiznMDz3R/lB2/52q0dqpFXc8SNfmJ4Mjn KFkL2a5ZxUumPSGIrfISXTv+RdBZG35G5fQpgok7zy8EB5Y9MERPGfPSp VewzgkET+08KSnSG5VFYWP1RTMLkWCozlXx85VxcdbFIkDrqlyDAhJitG s3++FIFzMFJBPMhmxVKmQC4Nw1kI4pubCp/12JrgisGoIQGz3/0voMh3L z9vW5NCCarnz+Z1kJtZ1U2/e+ePS3FcmrgbmTXDjn/rsSP8AgnV+ws0CS o4UhoHokd4XfKGkP8+TqpDPBIPFaTr9DAw1QL0D/NPKqyVPhN5qaZ2J6d Q==; X-CSE-ConnectionGUID: wkwlXbjrQ4CpGPggR27dNw== X-CSE-MsgGUID: GJCOI7wzQEKdOLtOajcGuQ== X-IronPort-AV: E=McAfee;i="6700,10204,11344"; a="40139720" X-IronPort-AV: E=Sophos;i="6.13,285,1732608000"; d="scan'208,217";a="40139720" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2025 01:23:30 -0800 X-CSE-ConnectionGUID: 9XvZmd6dRq6UUDWLz2P09w== X-CSE-MsgGUID: 2WHqE+63RtSQ+pO6FE3hbw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,285,1732608000"; d="scan'208,217";a="113598989" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by fmviesa008.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 14 Feb 2025 01:23:30 -0800 Received: from orsmsx603.amr.corp.intel.com (10.22.229.16) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.44; Fri, 14 Feb 2025 01:23:29 -0800 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.44 via Frontend Transport; Fri, 14 Feb 2025 01:23:29 -0800 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.44) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.44; Fri, 14 Feb 2025 01:23:28 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=CUvEOTX6eSjFrEGfGzmvARjtPd87DuXWI+eIDsOFa8Pk5gsTPzJHzlFPGOfOAK/exDAmNaJ88RSmNWHhvSouEmnsaNJ65HwHgk16mqT4TThGhlBNTIn5yzCMVJIKajKRpOevV0PhpxN6N9wsE+45EfKLz0ov1wsf/yfnIQHy5Qgeo/naEpFxUD0KkujngtzChgNjjc9yuy9GeRGCLfOYMZkBszCV8Tw1QxtG5pHBlK/17drZoKIPEk8qSoSshB3Q28Bl6O/H4+DYG5kg2mzVajbQyq5ir0jKUs6eZQ6qY4BndXPqg94SezVRk7gqoEfoO/eDD9lsau13pmP0hDgySw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MpRvZTHXtZ4GO4Pi8WwTmY5hQbnXmwy2rjvvkBrCHlo=; b=vO56polKnjS+zNTJOjmzxo+yy+0HWjUKUJEXu2iNtXVdxTva7iMfZpEwCZMtLr1MtT6/g0cKUGEzNOVXr+DW+Nm9VgW959cJ60nYcXagL8LStDq7fiN57+o772uwxtzGAaigcMjvzxGeVCS8XhEiVn1z1h3OVpkJwvPyLDc6jK8avjHLwlF6i8gEXfsveVIeUr2LMJq7MYGIsUWHp6zBKJyL/HBNQgwRA5iLD1aigARcHQw0IH6/o+Z9l6KOe5554684L74xMNjzf2uIdoaG3G/c8VBETI4OFwzP2IKpBz3242P2S70BCocbYtviaYW1r2ghfBV7iekWvPXaouqIGA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from PH8PR11MB6803.namprd11.prod.outlook.com (2603:10b6:510:1cb::12) by SA0PR11MB4639.namprd11.prod.outlook.com (2603:10b6:806:70::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8445.17; Fri, 14 Feb 2025 09:23:00 +0000 Received: from PH8PR11MB6803.namprd11.prod.outlook.com ([fe80::8680:ff9f:997:18b4]) by PH8PR11MB6803.namprd11.prod.outlook.com ([fe80::8680:ff9f:997:18b4%6]) with mapi id 15.20.8422.015; Fri, 14 Feb 2025 09:22:59 +0000 From: "Van Haaren, Harry" To: NAGENDRA BALAGANI , "users@dpdk.org" Subject: Re: Query Regarding Race Condition Between Packet Reception and Device Stop in DPDK Thread-Topic: Query Regarding Race Condition Between Packet Reception and Device Stop in DPDK Thread-Index: Adt+vEdloaqObPP2T4u6OUiIi+rKNwAA6AYr Date: Fri, 14 Feb 2025 09:22:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PH8PR11MB6803:EE_|SA0PR11MB4639:EE_ x-ms-office365-filtering-correlation-id: a521c4de-c5ff-4b3c-fc7c-08dd4cd92cc5 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|376014|1800799024|366016|8096899003|7053199007|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?f2OsfmVFAmRS75nyhY69v5NCpC2eDJW/2vys1+rSTHJtmoydBUsRDAOo+L?= =?iso-8859-1?Q?51Kj7QX1qiIQqa3OMWhe9DvLcyAnvrLfj3j+v0rtFVca1oiIGW3cNnSzwW?= =?iso-8859-1?Q?3j/iJe2LR8m3mVEus3oEaUXTkhe4wgTNNDR0Tmf/ZFzvRVDiYrkqudiJyr?= =?iso-8859-1?Q?KG6MJ4mHTU1QFFl9vQEO3yikJc0oZ+8jbQYmKusz63TgQzRIDFQkhJIEbj?= =?iso-8859-1?Q?OpfRLn8cfIcxxfU30dlUhFVYisNyRcxmx23CKShurW9mnd4smjC0XOsIkW?= =?iso-8859-1?Q?5TOF2UMR1uhi5zKKMuuFR95aG3PeEgnJCrWhnCUlyQ/ofB923e2x9OEmBq?= =?iso-8859-1?Q?ZbYqVBpjubUyhoXigx2OSQoTfsNJW2D6TvjDzDloq8Gl1Cb87iyjC9tz3W?= =?iso-8859-1?Q?ULjscHuVRviKcbHMCzTrE8L4BpriyIWj4tnAypvPhyYuiXNhgpDuBdZBPp?= =?iso-8859-1?Q?eyf+FmfZJj+++WRQ6BxQ7IHEnbXLQ49cIRs9JJ20rc7cjeZ6jKUODiKv/H?= =?iso-8859-1?Q?0p/X4F18gjshTcf8kJUXgViHFnUL+sOVQKYij4dH6TzThUyDhDnAdVkfez?= =?iso-8859-1?Q?yqM8aNjkxEH6wWhARiELLqw6zsjfuRjtLXBXUSf6wsd0TxWwSCPLn8lZl6?= =?iso-8859-1?Q?vnA3BRfYx40bLyDaF2nDI9lYpz+3yBzY98IKJCPOgAo3hbep8nVX3W69+B?= =?iso-8859-1?Q?xmwZEOyX3rWg/maEIE2pm7JgKQP4FENl2lZReD6df7SyrqqOl6UsiwIo2b?= =?iso-8859-1?Q?C7SWXGmimyhdX8lY5F8x4Ztzx6htfH8wKC4jVjPFVNJcGU8isb06IJuIBh?= =?iso-8859-1?Q?hqOurXvUVr2QbQlXeNcjtWNtvf+6vNL4lhNEf6XvUzzEaVLAVL1YqG4xNq?= =?iso-8859-1?Q?Ur2MwPSDWyn9KEI4aoY9gl0lPZprPHrdBTijSbbTSLIpsort39b5DbpL8o?= =?iso-8859-1?Q?K0QUNJJ1gpvbQn5h+gTsf1iVhTvqsjHqFIfcHNSvDfxv6tM+32zu5MRnJl?= =?iso-8859-1?Q?bNZbUw9pg0Dcb5xqdYSDCoVTUPe0RIuT6IMdAlCy3V6Bg2z9IYBgZzV2q8?= =?iso-8859-1?Q?ETKB5LYx//Sc048hw6+xhgWSvt46HYQ1oF05sF/uagM1wYTiFw1qC1kH2q?= =?iso-8859-1?Q?cOuuNSmOJ1pC0ZKdgjFTtXbytN7bjaZIg9FL3RmQU8x9vdAmEjzcD4aAsS?= =?iso-8859-1?Q?c7bnmTMPFtOpLV7IHu0cdOvQ7d0VfQ6X9wQuV4GP2WyxjXYze1VhpLBWMZ?= =?iso-8859-1?Q?zbYCywf6POzG/18xXQUz/jsgJ1SoPhL9jjniVbbJFn2IupDKkunho9sKm5?= =?iso-8859-1?Q?3Dt41rcrhsF5Y4XyUI8lHJ79royebr5PY/b34PI4Yu06IR6vRQdgnRczwA?= =?iso-8859-1?Q?NUsj3biNbQucEONyfq6f43AochTjMyeUg1pkQvLV2rx9uVc/YsIpzYMDNX?= =?iso-8859-1?Q?vYj2igjCnaeoRB677uDhOG+J6Q0WH6RH/1O/zg=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH8PR11MB6803.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(376014)(1800799024)(366016)(8096899003)(7053199007)(38070700018); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?F2HfzxQp8kEpZ98AsCUNYauq+lnIsw1PLJclWKi1dkaYpQ6mO+rURqeYBu?= =?iso-8859-1?Q?8/U8Uvo5mYgoG71kAzdRGPorNYYKIVBkY74pMjEx+lnQVBgaPC+fzZ4Dbs?= =?iso-8859-1?Q?AIksrOuv/gXhOwRrlpVPjrPmTJYHghYsc+WCCUoxe3W7nL+SUpBHv2VWCy?= =?iso-8859-1?Q?d0ON+zG/y6mbIgQ31yCcOENIofTKQp45qJ0+7FEIhL7hfiZhwsbx5VYI28?= =?iso-8859-1?Q?LJkDG68vKUYbH4dPWD5o6LAlX3+YWZhiQB9iK6nZnekaEkHVmM3H3PL26X?= =?iso-8859-1?Q?Vc96CmOV0pWpkgN34NPdTgGKXX1HNbBGIeN5btCW9qNIRwicz8pBfdBLgl?= =?iso-8859-1?Q?4boqJj0KoV0lXIcrAJ0F5dLf+DpXTjyV5BVZqu7zd9uIGCgfqGSOyXu8m6?= =?iso-8859-1?Q?uQySXCk9wj1IpLeY+mCJFoMz8DumcHuighhoZjUaIjH+H+cOElNHa+dbjL?= =?iso-8859-1?Q?rLTy1+KqZq2fAXdytTrOOjskAqXq2TKP36zG6S8DvFOU4R8oYRiwegKHU0?= =?iso-8859-1?Q?qthYHIF6hDVZZyOb1dWiiF8wkGOY2q2PKLKQgbUniOJ1Li1hKsjDD/2YNG?= =?iso-8859-1?Q?txHJTLyKGqTnWCO18X0WkFNi+fa6c58m/5jaRGZEiMSOcNdrm8TISqbGu2?= =?iso-8859-1?Q?0MwaQ2fYfRiI0cvA7MV/UgJgoD8mEkTJLEsTIDTRXq+HnS8ocKJqyO6T/G?= =?iso-8859-1?Q?vpCpCo5XKnYYyWFoNkx+pQTCz8o+IMtnKX3c+lcrxNkVrGrujGSKrL74R1?= =?iso-8859-1?Q?F1q7gmP+fvmLyYjCeL8lWlP7d1soQSLlYpVhbWAwfVBfn3Fu684evnGfh7?= =?iso-8859-1?Q?oXchN3oIVrBx+kZMbE7i1yjCKS1/lY3zCz6Xrt5d5C1ZRLxHhR3JXnJFpW?= =?iso-8859-1?Q?T/r3E3/lCoDRY7OElXn4hbOnl5ahqQ8lS3S5IgO9mBobbVipgQMG8qtAap?= =?iso-8859-1?Q?1xi/zjY1QNR2DEKcZl6bjF4RyifZqs/myPmzB7DkgXPlijDZpvHuAdjiCp?= =?iso-8859-1?Q?7OmG8qaGvPq2FMbNSLq/Pq3se8ck5OlCHFWv45smqp5hMdcrIlZ+Q8WOKY?= =?iso-8859-1?Q?z7ZYsGCqEn0jYv/YVc0CzCgl62+QSjVBDFOzjLKkiXkOUvRuTdiimoXEve?= =?iso-8859-1?Q?zuZ/mA57kwpieKjve4LdE2W0SHV8OoN5BjPjikU7HUSs5F100erVTIZojM?= =?iso-8859-1?Q?c5vmwoN0TTWq5zdx6agkVEiEv2coXlq3JxotZ65W7WJOL17xySPNQWZyQF?= =?iso-8859-1?Q?NopWxXEqqpLxczLPlgrxMhEb6BIgdjnhYP35N4za31eKjFRJ0J6hFkskQN?= =?iso-8859-1?Q?6fjKkM+6EC8Ey5z+w3ouUHOn2YmexQhjbTZXoPcbQvTW2TPmDlYujtWUop?= =?iso-8859-1?Q?Wknhv5sYO5VlL2VugFsbF3G0xTWsWbqwgLoZyjMHHCb6Gf3sUIoMztIPDv?= =?iso-8859-1?Q?QvHm2N2judyq1SSQcKa3L842zfJ089KsHMl0yu4GWUrUSJ1yI7PdQkvwFm?= =?iso-8859-1?Q?JCYaMtQfO8fMk4YQbpphBx5fHU1/ZQjNnQJUfu50Vgj+YrAujywgoXk+kp?= =?iso-8859-1?Q?6G7slnsN/ADTfpG8Pn/hR3rpCf0vUjtTWckuMVHvbI/bNaz5XDYwhV5RaM?= =?iso-8859-1?Q?teyJ5L5etkhviE21Y5squei3ujJM84Fqpm?= Content-Type: multipart/alternative; boundary="_000_PH8PR11MB6803CD852AB1E71D2D4B71AFD7FE2PH8PR11MB6803namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB6803.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a521c4de-c5ff-4b3c-fc7c-08dd4cd92cc5 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2025 09:22:59.9114 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: B9LP7aQo1uuyCG7eE9j2I2u9cH5nX3rZkn14Ln3BPTpi1O8bXqU2jVJMUdFksbFwvp+2M5uGSTTyF7+KIzbWKxnhUfEKNeVtZnOIeZ91QIE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR11MB4639 X-OriginatorOrg: intel.com X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --_000_PH8PR11MB6803CD852AB1E71D2D4B71AFD7FE2PH8PR11MB6803namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > From: NAGENDRA BALAGANI > Sent: Friday, February 14, 2025 8:43 AM > To: users@dpdk.org > Subject: Query Regarding Race Condition Between Packet Reception and Devi= ce Stop in DPDK > > Hi Team, Ni Nagendra, > We are facing a race condition in our DPDK application where one thread i= s reading packets from queue using rte_eth_rx_burst() , while another threa= d is attempting to stop the device using rte_eth_dev_stop(). This is causin= g instability, as the reading thread may still be accessing queues while th= e device is being stopped. This is as expected - it is not valid to stop a device while other cores ar= e using it. > Could you please suggest the best way to mitigate this race condition wit= hout impacting fast path performance? We want to ensure safe synchronizatio= n while maintaining high throughput. There are many implementations possible, but the end result of them all is = "ensure that the dataplane core is NOT polling a device that is stopping". 1) One implementation is using a "force_quit" boolean value (see dpdk/examp= les/l2fwd/main.c for example). This approach changes the lcore's "while (1)= " polling loop, and turns it into a "while (!force_quit)". (Note some nuanc= e around "volatile" keyword for the boolean to ensure reloading on each ite= ration, but that's off topic). 2) Another more flexible/powerful implementation could be some form of mess= age passing. For example imagine the dataplane thread and control plane (st= opping ethdev) thread are capable of communicating by sending an "event" to= eachother. When a "stop polling" event is recieved by the dataplane thread= , it disables polling just that eth device/queue, and responds with a "stop= ped polling" reply. On recieving the "stopped polling" event, the thread th= at wants to stop the eth device can now safely do so. Both of these implementations will have no datapath performance impact: 1) a single boolean value check (shared state cache-line, likely in the cor= e's cache) per iteration of polling of the app is super lightweight 2) an "event ringbuffer" check (when empty, also shared-state, likely in ca= che) per iteration is also super light. General notes on the above: There's even an option to only check the boolean/event-ringbuffer once ever= y N iterations: this will cause even less overhead, but will increase the l= atency of event action/reply on the datapath thread. As almost always, it d= epends on what's important for your use-case! The main difference between implementation 1) and 2) above can be captured = by this phrase: "Do not communicate by sharing memory; instead, share memor= y by communicating.", which I read at the Rust docs here: https://doc.rust-= lang.org/book/ch16-02-message-passing.html. 1) literally shares memory (bot= h threads access the force_quit value directly). 2) focusses on communicati= ng: which enables avoiding the race condition in a more powerful/elegant wa= y (and future proof too - it allows adding new event types cleanly, which t= he force_quit bool value does not.) I like this design-mentality, as it is = a good/high-performance/scalable way of interacting between threads, and sc= ales to future needs too: so I recommend approach 2. > Looking forward to your insights. > > Regards, > Nagendra Regards, -Harry --_000_PH8PR11MB6803CD852AB1E71D2D4B71AFD7FE2PH8PR11MB6803namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> From: NAGENDRA BALAGANI <nagendra.balagani@oracle.com>
> Sent: Friday, February 14, 2025 8:43 AM
> To: users@dpdk.org <users@dpdk.org>
> Subject: Query Regarding Race Condition Between Packet Reception and D= evice Stop in DPDK
>  
> Hi Team,

Ni Nagendra,

> We are facing a race condition in our DPDK application where one threa= d is reading packets from queue using rte_eth_rx_burst() , while another th= read is attempting to stop the device using rte_eth_dev_stop(). This is cau= sing instability, as the reading thread may still be accessing queues while the device is being stopped.

This is as expected - it is not valid to stop a device while other cores ar= e using it.

> Could you please suggest the best way to mitigate this race condition = without impacting fast path performance? We want to ensure safe synchroniza= tion while maintaining high throughput.

There are many implementations possible, but the end result of them all is = "ensure that the dataplane core is NOT polling a device that is stoppi= ng".

1) One implementation is using a "force_quit" boolean value (see = dpdk/examples/l2fwd/main.c for example). This approach changes the lcore's = "while (1)" polling loop, and turns it into a "while (!force= _quit)". (Note some nuance around "volatile" keyword for the boolean to ensure reloading on each iteration, but that's off topic).<= /div>

2) Another more flexible/powerful implementation could be some form of mess= age passing. For example imagine the dataplane thread and control plane (st= opping ethdev) thread are capable of communicating by sending an "even= t" to eachother. When a "stop polling" event is recieved by the dataplane thread, it disables polling just that e= th device/queue, and responds with a "stopped polling" reply. On = recieving the "stopped polling" event, the thread that wants to s= top the eth device can now safely do so.

Both of these implementations will have no datapath performance impact:
1) a single boolean value check (shared state cache-line, likely in the cor= e's cache) per iteration of polling of the app is super lightweight
2) an "event ringbuffer" check (when empty, also shared-state, li= kely in cache) per iteration is also super light.

General notes on the above:
There's even an option to only check the boolean/event-ringbuffer once ever= y N iterations: this will cause even less overhead, but will increase the l= atency of event action/reply on the datapath thread. As almost always, it d= epends on what's important for your use-case!

The main difference between implementation 1) and 2) above can be captured = by this phrase: "Do not communicate by sharing memory; instead, share = memory by communicating.", which I read at the Rust docs here: https:/= /doc.rust-lang.org/book/ch16-02-message-passing.html. 1) literally shares memory (both threads access the force_quit value direc= tly). 2) focusses on communicating: which enables avoiding the race conditi= on in a more powerful/elegant way (and future proof too - it allows adding = new event types cleanly, which the force_quit bool value does not.) I like this design-mentality, as it is a = good/high-performance/scalable way of interacting between threads, and scal= es to future needs too: so I recommend approach 2.

> Looking forward to your insights.
>
> Regards,
> Nagendra  

Regards, -Harry
--_000_PH8PR11MB6803CD852AB1E71D2D4B71AFD7FE2PH8PR11MB6803namp_--