Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
API additions for connecting non-Send closures and thread-safety fixes to the main context channel and futures #541
After checking that the callback of the main context channel was always dropped from the correct thread, this check was actually failing often. I refactored the code now so that this can't happen anymore and we always ensure that non-Send values are only ever accessed from the correct thread.
Similar things happened with the GSource in the futures executor, which is also fixed and refactored now.
Overall the code should be much simpler now, and more correct!
… from a Sender Otherwise we would unref it potentially from another thread and then cause the callback of the source to be dropped from a different thread than where it was created. This would be wrong as the callback closure is not Send! Do this by counting the number of senders separately instead of re-using the strong count of the channel Arc.
These are not needed if all the signalling is happening by setting the ready time of the GSource.
…opped from a different thread The TaskSource now only keeps the Future that has to be polled and a reference to a Waker, which is a child source of the TaskSource. This Waker is passed as waker to the future's poll() function and is potentially passed to other threads and might also outlive the TaskSource but its only job is to wake up the TaskSource. The TaskSource is never passed to different threads and is internal to the futures executor. Also remove the check/prepare functions from the GSources as they're not needed when using child sources or triggering the GSources via setting the ready time.
On 19 November 2019 00:31:33 EET, Guillaume Gomez ***@***.***> wrote: If the CI was ok before, then it means it's not checked correctly. Please either update the travis build or add tests. :D
Run the tests without the last commits and you'll see them failing if you run them often enough. They fail with the addition of the first commits because that's adding the checks for usage and dropping on the correct thread. Previously that was not checked and would've caused safety issues instead.…
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.