Consider fork-like interface that doesn't schedule new coroutine immediately
See original GitHub issueCurrently when calling fork
, the new forked coroutine gets to run immediately, and the originating coroutine waits until fork
returns before continuing. It might be useful to provide a way to queue the forked coroutine to run after the current one yields back to the scheduler.
_Originally posted by @garmin-mjames in https://github.com/cocotb/cocotb/pull/1526#issuecomment-605092873_
Issue Analytics
- State:
- Created 3 years ago
- Comments:17 (17 by maintainers)
Top Results From Across the Web
runBlocking with Android's Main.immediate scheduler locks ...
I've been trying to figure out why this code freezes on Android (when started on the main thread): runBlocking { Log.i("test", ...
Read more >Coroutines - Unity - Manual
Calling Destroy(example) (where example is a MonoBehaviour instance) immediately triggers OnDisable and the coroutine is processed, effectively stopping it.
Read more >Kotlin Coroutines patterns & anti-patterns | by Dmytro Danylyk
In the example above doWork function launches new coroutine (1) which may throw ... UI inside your root coroutine, don't launch it with...
Read more >Reactor 3 Reference Guide
Reactor is a fully non-blocking reactive programming foundation for the JVM, with efficient demand management (in the form of managing “ ...
Read more >Best practices for coroutines in Android
Don't hardcode Dispatchers when creating new coroutines or calling withContext . ... Default directly, inject it instead
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@eric-wieser I forgot that was fixed… The second suggestion is equivalent to what we have now but uses an
Event
, instead of simply callingfork
later. But the first should be sufficient for our needs.But if
await NullTrigger()
does what we need it to, maybe we could codify that pattern and add documentation; that way we can consider this issue closed? I’m thinking something simple like:I took this issue as a general complaint about the scheduler being recursive and causing a number of bugs, but that should probably be in a separate issue.
@garmin-mjames I think we should change that behavior. If we are going to break the scheduler interface, we should just break it and do what we need to make it better. We need to queue up issues and detail what the end product of a scheduler rewrite should look like.
This is the test I used to check the behavior of
NullTrigger()
:The output shows
NullTrigger
not rescheduling.Funnily enough, that test fails too! Yay scheduler!
With
COCOTB_SCHEDULER_DEBUG
: sim.log.EDIT:
fork
ing the coroutines before passing them toCombine
shows it runs all the coroutines, but still in order and it still fails.