Concurrency update
Motivation
Library being written even before async/await. So now, even though it supports it partly, with upcoming Swift 6 release and strict concurrency we should update it.
Plan
First steps after looking at the state of library, should be straightforward (in a way):
- [ ] Check what type should be Sendable. Things like messages, peers and nodes are first to look at.
- [ ] Wonder if Codable implementation should be part of library itself, rather than each implementation doing on it's own.. I would even argue that SWIMPeer should be Codable, as it's being used in messages.
- [ ] Remove DispatchTime in favour of Duration and ContinuationClock.Instant
- [ ] Enable strict concurrency mode and check what else should be updated. Probably closures and classes, using Mutex and etc.
- [ ] Update tests.
- [ ] Update examples.
- [ ] Update CI when final Swift 6 images will be released?!
Will assume, that when finished library will be compatible with Swift 6. But here comes a bit different question—could code and design be even more clear having async/await, actors and etc. To answer this question, as a next steps I want to remove EventLoop and Promises in SWIMNIOExample and see how it works. Based on that experience would be interesting to check if any design updates even needed.
@ktoso I will create a draft PR, so it will be easier for me to return to this topic from time to time and not to forget. Basically it's already working at that stage, but I've been updating all the errors and warning reactively, so not much thought in it. :) Now a time to think a bit more about design overall. Though, if you already have some thoughts on current progress—please feel free to comment.
We now have CI again so let's give this a review tomorrow and merge maybe :)
If you'd run
swift format . --recursive --in-place
that will resolve many of the conflicts i think
lot's of conflicts, will probably have a good time resolving