From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id C3E795902 for ; Mon, 29 Sep 2014 08:34:06 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 28 Sep 2014 23:40:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,618,1406617200"; d="scan'208";a="580474492" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga001.jf.intel.com with ESMTP; 28 Sep 2014 23:40:39 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.200]) by IRSMSX101.ger.corp.intel.com ([169.254.1.201]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 07:40:38 +0100 From: "Wodkowski, PawelX" To: Neil Horman , "Ananyev, Konstantin" Thread-Topic: [dpdk-dev] [PATCH v2] Change alarm cancel function to thread-safe: Thread-Index: AQHP2MAapayPUkT5UUGj9XqXyFJ3T5wR4sKAgAAPjwCAABZmAIAAZLsAgADPUACAAB2vsIAAAhgAgAAUZmCAAAJtAIAACzAAgAALEACAAB2GAIAAGaqAgALq0gCAAE0RAIAAsPTw Date: Mon, 29 Sep 2014 06:40:37 +0000 Message-ID: References: <20140926114630.GA3930@hmsreliant.think-freely.org> <20140926134014.GB3930@hmsreliant.think-freely.org> <20140926150156.GB5619@hmsreliant.think-freely.org> <2601191342CEEE43887BDE71AB9772582137D88E@IRSMSX104.ger.corp.intel.com> <20140926162134.GE5619@hmsreliant.think-freely.org> <2601191342CEEE43887BDE71AB9772582137D95F@IRSMSX104.ger.corp.intel.com> <20140926193905.GH5619@hmsreliant.think-freely.org> <2601191342CEEE43887BDE71AB9772582138410B@IRSMSX104.ger.corp.intel.com> <20140928204754.GC4012@localhost.localdomain> In-Reply-To: <20140928204754.GC4012@localhost.localdomain> Accept-Language: pl-PL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to thread-safe: 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: Mon, 29 Sep 2014 06:34:07 -0000 > Yes, this is my concern exactly. >=20 > > If that's so, then I suppose we can do: make alarm_cancel() to return = a > negative value for the case #3 (-EINPROGRESS or something). > > Something like: > > ... > > if (ap->executing =3D=3D 0) { > > LIST_REMOVE(ap,next); > > rte_free(ap); > > count++; > > ap =3D ap_prev; > > } else if (pthread_equal(ap->executing_id, pthread_self()) =3D=3D 0) { > > executing++; > > } else { > > ret =3D -EINPROGRESS; > > } > > ... > > return ((ret !=3D 0) ? ret : count); > > > > So the return value will be > 0 for #1, 0 for #2, <0 for #3. > > As I remember, you already suggested something similar in one of the pr= evious > mails. > Yes, I rolled the API changes I suggested in with this model, because I w= anted > to be able to do precise specification of a timer instance to cancel, but= if > we're not ready to make that change, I think what you propose above would= be > suffficient. Theres some question as to weather we would cancel timers t= hat > are > still pending on a return of -EINPROGRESS, but I think if we document it > accordingly, then it can be worked out just fine. >=20 > Best > Neil >=20 Image how you will be damned by someone that not even notice you change and he Is managing some kind of resource based on returned number of=20 set/canceled timers. If you suddenly start returning negative values how th= ose application will behave? Silently changing returned value domain is evil in= its=20 pure form. >>From my point of view, problem is virtual because this is user application = task to=20 know what it can and what it not. If you really want to inform user applica= tion about timer state you can introduce API call which will interrogate timers = list and return appropriate value, but for god sake, do not introduce untraceabl= e bugs. Pawel