ResealTimer::set_min_timer causes a crash #1069

Activity

1. majecty

   added

   bugSomething isn't workingSomething isn't working

   miner

   on Jan 9, 2019
2. sgkim126 commented on Jan 9, 2019

   

   sgkim126

   on Jan 9, 2019

   Last edited by sgkim126

   Contributor

   More actions

   @foriequal0
   I have three questions.

   1. Is the order of schedule and cancel in the same thread guaranteed?
   2. What happens if the scheduled token is scheduled again?
   3. What happens if the canceled token is canceled again?
3. foriequal0 commented on Jan 9, 2019

   

   foriequal0

   on Jan 9, 2019

   Last edited by foriequal0

   Contributor

   More actions

   @sgkim126

   1. Yes
      Schedule::schedule function puts a ScheduleStateControl to the SchedulerInner (with lock), and Schedule::cancel function finds ScheduleStateControl from it, and it should be sequential. But even if it succeeds to fire cancel signal, it can race with on_timeout scheduling (callback could be called)

   2. Before the token is expired, it should return Err(TokenAlreadyScheduled), otherwise, it should succeed.

   3. It just returns false.
4. sgkim126 commented on Jan 9, 2019

   

   sgkim126

   on Jan 9, 2019

   Last edited by sgkim126

   Contributor

   More actions

   @majecty I discussed with @foriequal0
   IMO, the atomic cancle_and_schedule_once works in the same if

   1. the order in the same transaction is guaranteed
   2. it's okay to schedule already scheduled token
   3. it's okay to cancel already canceled token

   And currently, the only error returned by schedule_once is AlreadyScheduled.
   So I think it's okay if you just ignore the error of schedule_once function.
5. majecty commented on Jan 9, 2019

   

   majecty

   on Jan 9, 2019

   Author

   More actions

   OK, I'll fix it by ignoring AlreadyScheduled error.
6. sgkim126

   added this to the Release Candidate milestone on Jan 9, 2019
7. mergify

   closed this as completedin #1075on Jan 10, 2019