setFirst and setNext behavior eliminates the race condition when the thread calling the schedulePeriodically gets stalled right after receiving the subscription but before setting it on the container-subscription it is returning and potentially overwriting a subscription token of the next scheduled period. The "giving up" here is of no concern because at the time it would set an old subscription, there is already a new subscription because the first iteration already completed and the old can just be discarded.