From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <pawelx.wodkowski@intel.com>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
by dpdk.org (Postfix) with ESMTP id C3E795902
for <dev@dpdk.org>; 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" <pawelx.wodkowski@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>, "Ananyev, Konstantin"
<konstantin.ananyev@intel.com>
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: <F6F2A6264E145F47A18AB6DF8E87425D12B3A553@IRSMSX102.ger.corp.intel.com>
References: <20140926114630.GA3930@hmsreliant.think-freely.org>
<F6F2A6264E145F47A18AB6DF8E87425D12B39EB5@IRSMSX102.ger.corp.intel.com>
<20140926134014.GB3930@hmsreliant.think-freely.org>
<F6F2A6264E145F47A18AB6DF8E87425D12B39F15@IRSMSX102.ger.corp.intel.com>
<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" <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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=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