Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to thread-safe:

["Wodkowski, PawelX" <pawelx.wodkowski@intel.com>]

> >
> > 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
> > set/canceled timers. If you suddenly start returning negative values how those
> > application will behave? Silently changing returned value domain is evil in its
> > pure form.
> 
> As I can see the impact is very limited.

It is small impact to DPDK but can be huge to user application:
Ex:
If someone use this kind of expression in callback (skipping user app serialization part):
callback () {
...
some_simple_semaphore += rte_alarm_cancel(...));
...
}

Anywhere in the code:
...
If (some_simple_semapore) {
	some_simple_semapore --;
	if (rte_eal_alarm_set(...) != 0)
		some_simple_semapore ++;
}
...

1. Do you notice the change in cancel function?
2. How many hours you spend to find this issue in case of big app/system?

> Only code that does check for (rte_alarm_cancel(...) == 0/ != 0) inside alarm
> callback function might be affected.
> From other side, indeed, there could exist situations, when the caller needs to
> know
> was the alarm successfully cancelled or not.
> And if not by what reason.
> 

I can extend API of rte alarms to add alarm state checking in next patch,  but for 
now, since this is not urgent I think original patch  v2 should be enough.

Pawel