Question: cocotb.task is not cancelable

[Febbe]

I have a weird issue with some tasks wrapping coroutines passed to cocotb.triggers.First that they are neither killed or canceled.
Since one coroutine throws a SimTimeoutError and the other is the failing testcase, it is mandatory to kill the other coroutine when the first is done.
This is however implemented in First, but nothing happens, those coroutines just continue to run. Shouldn't an asyncio.CancelledError be raised in all the child coroutines?

I am using:
cocotb 1.8.1
cocotb-bus 0.2.1
Fedora release 38 (Thirty Eight)
python, sys, pyenv 3.11.7

async def with_timout(awaitable, awaitable_timout):
    print("started await with timeout")
    async def throw_timeout(awaitable_timout):
        print("await end in throw_timeout")
        await awaitable_timout
        print("timeout! raise exception")        
        raise cocotb.result.SimTimeoutError()         
    
    awt = cocotb.start_soon(awaitable)
    awtt = cocotb.start_soon(throw_timeout(awaitable_timout))
    return await cocotb.triggers.First(awt, awtt)

#[...]
await with_timout(test_end_cond(self), ClockCycles(cocotb.top.clk, 100))

When the timeout is not reached, the TB freezes, because the Clock is cleaned and the ClockCycles coroutine does not cancel its execution.

[ktbarrett]

There are two issues here.

1. Throwing CancelledError in cancelled tasks.

I just realized this isn't in an issue yet, but #2679 mentions it. It's on the schedule for 2.0.

2. First should kill tasks.

This is contentious. Perhaps the user wants to potentially wait for a task to end, but doesn't want to kill it if it doesn't end. asyncio.wait does not kill child tasks, but lets them continue to run.

This is however implemented in First, but nothing happens

What you think is being cancelled is not what is being cancelled. The tasks in First that are cancelled are implementation details of First, they are not intended to cancel the tasks passed in.

[ktbarrett]

The issue with the current design of tasks, that is also present in asyncio, is that tasks are allowed to be free rather than constrained to their use-case. It's very flexible, but really just complicates everything. Our plan for 2.0 is to design away from "free" tasks by categorizing free tasks started with cocotb.start_soon as symmetric to the test task, while the kinds of tasks used in First and Combine are asymmetric, which we will implement using a mechanism to enforce structured use, like is seen with trio's nursery. See #3583.

[Febbe]

The more I think about this, the more it does make sense. Sorry for my confusions, I am learning python and cocotb right now, and I am used to C++ where all resources are cleaned due to RAII after they lose all of their lifetime.

Are all tasks stored in the scheduler with a weak reference, like in asyncio? I assume not, since the scheduler does not quit when I leave the main test coroutine and all handles are cleared with a running coroutine?

[ktbarrett]

Tasks are global objects, they don't have local lifetime. asyncio Tasks are the same as cocotb's in this regard. The scheduler ends when the main test coroutine finishes. If it doesn't it's because there is a bug.

[Febbe]

I found the bug, I added a Timer in the hope to prevent the SIGSEG in vsimk, but that didn't helped and I accidentally added it as a timer of 1 sec, which is pretty long, since the second is simulated. After removing the FallingEdge trigger / just using the ClockCircle trigger, my TB works fine.
Thank you for your help.