> >
> > 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
