# Motoko: forcing a round wait in self call **URL:** \ **Category:** Language Support\ **Tags:** Motoko\ **Created:** [May 22, 2023, 11:31am UTC](https://forum.dfinity.org/t/motoko-forcing-a-round-wait-in-self-call/20139 "2023-05-22T11:31:16Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [May 22, 2023, 11:31am UTC](https://forum.dfinity.org/t/motoko-forcing-a-round-wait-in-self-call/20139/1 "2023-05-22T11:31:16Z")
I want to await a call to an update on my own canister. Is there a good strategy to make sure this goes through a full consensus round? I thought about retrying and checking the timestamp and throwing it away if it hasn’t changed, but I don’t want to just self call a hundred times and burn cycles. Edit: I know a timer would be better here, but the interop party has requested a single atomic call and I basically want to block until I’ve processed a number of things. ---
**Author:** ![Vivienne](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/vivienne/32/29170_2.png) [@Vivienne](https://forum.dfinity.org/u/Vivienne)\ **Post date:** [May 22, 2023, 1:44pm UTC](https://forum.dfinity.org/t/motoko-forcing-a-round-wait-in-self-call/20139/2 "2023-05-22T13:44:42Z")
Can you please clarify? Are you looking for a 1-round delay function or are you asking merely about self-awaiting? A self-await works just like any other await (specifically excluding `await*`), but your call may get scheduled in the same round of consensus as a short-circuit mechanism. Control still only returns to the calling site after that call has finished ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [May 22, 2023, 2:20pm UTC](https://forum.dfinity.org/t/motoko-forcing-a-round-wait-in-self-call/20139/3 "2023-05-22T14:20:45Z")
I want to specifically delay one round. ---
**Author:** ![dsarlis](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/dsarlis/32/689_2.png) [@dsarlis](https://forum.dfinity.org/u/dsarlis)\ **Post date:** [May 23, 2023, 8:43am UTC](https://forum.dfinity.org/t/motoko-forcing-a-round-wait-in-self-call/20139/4 "2023-05-23T08:43:59Z")
You can’t delay by one round (or X rounds for that matter) because the round concept is not exposed to the canister developers. > Edit: I know a timer would be better here, but the interop party has requested a single atomic call and I basically want to block until I’ve processed a number of things. If you want to block until you’ve processed a number of things, it sounds like you would be able to do one self-call once the last thing you’ve processed is done and then move on? Or maybe I don’t understand what you have in mind exactly. ---
**Author:** ![berestovskyy](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/berestovskyy/32/3989_2.png) [@berestovskyy](https://forum.dfinity.org/u/berestovskyy)\ **Post date:** [May 23, 2023, 9:23am UTC](https://forum.dfinity.org/t/motoko-forcing-a-round-wait-in-self-call/20139/5 "2023-05-23T09:23:15Z")
Probably, the easiest way to wait until the next round is to use [timers](https://internetcomputer.org/docs/current/motoko/main/base/Timer). Setting a one-off timer with a minimum 1ns delay should do the trick. ---
**Author:** ![ZenVoich](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/zenvoich/32/5969_2.png) [@ZenVoich](https://forum.dfinity.org/u/ZenVoich)\ **Post date:** [May 23, 2023, 9:54am UTC](https://forum.dfinity.org/t/motoko-forcing-a-round-wait-in-self-call/20139/6 "2023-05-23T09:54:00Z")
This is not self call, but may be helpful `await Random.blob();` ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [May 23, 2023, 10:00am UTC](https://forum.dfinity.org/t/motoko-forcing-a-round-wait-in-self-call/20139/7 "2023-05-23T10:00:00Z")
I have a very specific use case here. I’m guessing it would be possible since before you HAD to wait one round. The use case is perceived atomicity for the client. They’ve asked to make a call and not have it return until finished. I need to alert other canisters via one shot, but I only want to alert them one at a time and give them time to revert to an endpoint and I’ll search for their response before sending the next notification. Currently I can’t await a timer can I? ---
**Author:** ![free](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/free/32/615_2.png) [@free](https://forum.dfinity.org/u/free)\ **Post date:** [May 23, 2023, 1:42pm UTC](https://forum.dfinity.org/t/motoko-forcing-a-round-wait-in-self-call/20139/8 "2023-05-23T13:42:04Z")
Actually, a timer will only trigger 2 rounds out of 3 in the presence of messages. @ZenVoich’s suggestion to use `Random.blob()` sounds like your best bet. Although I’m not clear on how everything is supposed to fit together. Why are you sending one shot messages and then awaiting some side-effect of said message? Why do you expect that said side-effect will take one round to materialize? (it may well do so within the same round. Or take multiple rounds.) ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [May 23, 2023, 2:13pm UTC](https://forum.dfinity.org/t/motoko-forcing-a-round-wait-in-self-call/20139/9 "2023-05-23T14:13:16Z")
> [@free](#): > > Although I’m not clear on how everything is supposed to fit together. Why are you sending one shot messages and then awaiting some side-effect of said message? Why do you expect that said side-effect will take one round to materialize? (it may well do so within the same round. Or take multiple rounds.) The target of the notification can be specified by the caller or elected by a subscriber, but they will be canisters not in our control. We can’t await their reply. > Random.blob() I thought about this or just making sure we call something cheap on another subnet…maybe querying a balance from ICP canister which is guaranteed to be on another subnet. I’d need to find the cheapest way and the minimum number of rounds. ---
**Author:** ![timo](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/timo/32/5543_2.png) [@timo](https://forum.dfinity.org/u/timo)\ **Post date:** [May 23, 2023, 2:19pm UTC](https://forum.dfinity.org/t/motoko-forcing-a-round-wait-in-self-call/20139/10 "2023-05-23T14:19:34Z")
Is this relevant? [Ic-barrier: Withhold responses, for testing etc](https://forum.dfinity.org/t/ic-barrier-withhold-responses-for-testing-etc/9351) Old thread, called ic-barrier, it is about externally controlling when a call returns, with some trick. ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [May 23, 2023, 4:04pm UTC](https://forum.dfinity.org/t/motoko-forcing-a-round-wait-in-self-call/20139/11 "2023-05-23T16:04:12Z")
This looks very interesting. It looks like it uses actually stopping the canister. Unfortunately, this won’t work for us because we need to process other incoming requests. ---
**Author:** ![timo](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/timo/32/5543_2.png) [@timo](https://forum.dfinity.org/u/timo)\ **Post date:** [May 23, 2023, 6:47pm UTC](https://forum.dfinity.org/t/motoko-forcing-a-round-wait-in-self-call/20139/12 "2023-05-23T18:47:51Z")
I thought you’d build in one hop through a proxy canister and stop that one. ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [May 23, 2023, 8:33pm UTC](https://forum.dfinity.org/t/motoko-forcing-a-round-wait-in-self-call/20139/13 "2023-05-23T20:33:32Z")
Ah…that makes sense. Let me think about it a bit more.