> > As I remember the purpose of the patch was to fix the race condition inside > > rte_alarm library. > > I believe that the patch provided by Michal & Pawel fixes the issues you > > discovered. > > If you think, that is not the case, could you please provide a list of > > remaining issues? > > Excluding ones that you just don't like it, and you are not happy with > > rte_alarm API in total?
> Gladly. As Pawel explained the race, its possible that, after calling > rte_eal_alarm_cancel, an in-flight execution of an alarm callback may still be > running. The problem with that ostensibly is that data which is being > accessed > by the callback might be then accessed in parallel with another process > leading > to data corruption or some other problem. The issue I have with his patch is > that it doesn't completely close the race. While it does close the race for > the > condition in whcih thread B is running the alarm callback while thread A is > executing the cancel operation, it does not close the case for when a single > thread B is running the cancel operation, as the in-flight execution itself is > still active. A bit puzzled here: Are you saying that calling alarm_cancel() for itself inside eal_alarm_callback() might cause a problem? I still don't see how. > If such a cancellation occurs via an intermediary function (i.e. > one which is not aware that it is explicitly running an alarm callback, which > signals another thread to execute via some other method (ipc communication, > etc), the same data corruption may occur, because the canceled and complete > guarantee has been violated. >
