cocotb: Consider fork-like interface that doesn't schedule new coroutine immediately
Currently 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_
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 17 (17 by maintainers)
@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.@ktbarrett I agree. But,
NullTrigger
won’t work, as you noted up-thread: