From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wodkowski, PawelX" Subject: Re: [PATCH v2] Change alarm cancel function to thread-safe: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev-VfR2kkLFssw@public.gmane.org" To: Neil Horman , "Ananyev, Konstantin" Return-path: In-Reply-To: <20140928204754.GC4012-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> Content-Language: en-US List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" > 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