Open shaan7 opened 1 month ago
Hi Shantanu, thanks for looking at this! I like the idea to resume the coroutine instead of basically leaking it if the sender object is destroyed. I think that we as poor design decision on my side when I initially implemented that into the qCoro()
wrapper. Unfortunately I don't think we can easily retro-fit that into qCoro()
, so I'm all for your solution with qCoroWatch()
.
@danvratil I've cleaned up the implementation and also updated the documentation. Just to make sure the API and behavior isn't awkward, I'll use it for a few days in a real project. If everything is good, I'll mark this PR ready for review.
Thanks for taking another look @danvratil, I still have to finish the implementation in the project I used it in. Once it has gone through some testing and I'm more confident of this, I'll open the PR for review.
I think I also need to check at the CI jobs that are failing on this PR, lets see when I get to it.
DRAFT: I'm only starting to use coroutines in a real project, so treat this as a PoC. I'd first like to know if this approach is acceptable. I also saw the
guardThis
implementation (#191) but that seems to solving a different problem. If yes, I'll clean this up so to share some of theQCoroSignal
code.It is possible for a sender QObject to be deleted before it gets a chance to emit a signal that we are
co_await
'ing on. In such a case, the coroutine will never be resumed. A side-effect of this is that all variables that are local to that coroutine will never get deallocated and will stay in limbo forever.For example, the following snippet:
The object
obj
will never get freed ifthis
is deleted by something else (in a real life case, this can happen due to some conditions which require us to reload the current "project" in our app).Using the new function
qCoroWatch
instead ofqCoro
let you do this:As I said above, I'm only starting to use coroutines so it is possible that this has some limitations that I'm unaware of. I'm open to trying other approaches to solve the problem.