Issues with receiving with CoChannel (and possibly CoScope)

[funct7]

I noticed some weird behavior in my projects concerning CoChannels, and I wasn't sure if I was using it wrong or there was something buggy going on.

I have a scoped coroutine running and

1. The coroutine crashes when self is captured with unowned.
2. The receiving end slows down as new coroutines are launched using the same channel.

Not sure if I'm explaining the situation correctly, so I have a demo target here.

I also noticed that all the CoScopes are kepts around when the memory graph debugger is run like so:

The objects that own the CoScope instances are deallocated as expected.

The slowing down (or rather the skipping values) corresponds to the number of zombie CoScope instances. So when there are four CoScope instances lying around, the log prints like so

9122080394873498997
showInt(_:) 9122080394873498997
4655395568503796474
432049987236061310
1887288328159798314
1946205301628222178
showInt(_:) 1946205301628222178

(I also noticed other weird behavior with my real project like objects captured by the SwiftCoroutine and not deallocating, but I'm not sure if it's in any way related to the issue demonstrated by the sample project. I can provide further information if you're interested.)

Sorry about the haphazard reporting, but it was hard to determine if they all pointed to the same cause or if they were all separate, so I decided to just lay it out.

[belozierov]

@funct7 Hi, it's true that there is a leak in startCoroutine() when you pass CoScope. I'll fix it in next release. To fix it in current release, please don't pass scope parameter in startCoroutine() or add scope.cancel() in Reactor.deinit().

Thank you 🙂

[funct7]

Thank you. Once it's fixed, I'll see if other issues are also resolved.

[belozierov]

@funct7 You can try with this fix - https://github.com/belozierov/SwiftCoroutine/releases/tag/2.1.10

[funct7]

Most of the issues have gone away--also with my real project. Thank you so much!

The coroutine still crashes when self is captured with unowned, but I'm guessing it's because the block of code is not guaranteed to be canceled as soon as self and CoScope assoiciated with it is deallocated.