[PR #391] [MERGED] Make Paginator Send to enable scheduling onto a multithreaded runtime #430

New issue

Closed

opened 2026-02-27 20:24:43 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 20:24:43 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/ramsayleung/rspotify/pull/391
Author: @darkwisebear
Created: 2/25/2023
Status: ✅ Merged
Merged: 3/1/2023
Merged by: @ramsayleung

Base: master ← Head: paginator-add-send-sync

📝 Commits (2)

f8e4b52 Add test to verify thread safety bounds on Paginator
41d5273 Mark paginator as thread safe

📊 Changes

1 file changed (+49 additions, -10 deletions)

View changed files

📝 src/clients/pagination/stream.rs (+49 -10)

📄 Description

Description

Paginator is in fact a boxed trait object. However, it doesn't implement Send which is a requirement when scheduling onto a async multithreaded scheduler.

Motivation and Context

Using a Paginator which is not Send will also make the enclosing Future not Send. Therefore , when using tokio with the default scheduler, this will only work in the main thread.

Dependencies

None.

Type of change

Please delete options that are not relevant.

New feature (non-breaking change which adds functionality)

How has this been tested?

The first commit adds a test that sets Sync, which multithreaded async schedulers usually have. This test will not compile without modifying the code, just like if you try to schedule a future using a Paginator without a Send bound.

Please also list any relevant details for your test configuration

Using a Future enclosing an (async) Paginator, scheduled onto the tokio multithreaded scheduler.

Is this change properly documented?

Since this change only relaxes requirements for the user of the Paginator, no documentation change was made.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/ramsayleung/rspotify/pull/391 **Author:** [@darkwisebear](https://github.com/darkwisebear) **Created:** 2/25/2023 **Status:** ✅ Merged **Merged:** 3/1/2023 **Merged by:** [@ramsayleung](https://github.com/ramsayleung) **Base:** `master` ← **Head:** `paginator-add-send-sync` --- ### 📝 Commits (2) - [`f8e4b52`](https://github.com/ramsayleung/rspotify/commit/f8e4b52bebdb1fbb35800ff4c3d370d7aed0f285) Add test to verify thread safety bounds on Paginator - [`41d5273`](https://github.com/ramsayleung/rspotify/commit/41d527336257e2cbd70728d9b2e8290dd9e13b31) Mark paginator as thread safe ### 📊 Changes **1 file changed** (+49 additions, -10 deletions) <details> <summary>View changed files</summary> 📝 `src/clients/pagination/stream.rs` (+49 -10) </details> ### 📄 Description ## Description Paginator is in fact a boxed trait object. However, it doesn't implement Send which is a requirement when scheduling onto a async multithreaded scheduler. ## Motivation and Context Using a Paginator which is not Send will also make the enclosing Future not Send. Therefore , when using tokio with the default scheduler, this will only work in the main thread. ## Dependencies None. ## Type of change Please delete options that are not relevant. - [X] New feature (non-breaking change which adds functionality) ## How has this been tested? The first commit adds a test that sets `Sync`, which multithreaded async schedulers usually have. This test will not compile without modifying the code, just like if you try to schedule a future using a Paginator without a Send bound. Please also list any relevant details for your test configuration - Using a Future enclosing an (async) Paginator, scheduled onto the tokio multithreaded scheduler. ## Is this change properly documented? Since this change only relaxes requirements for the user of the Paginator, no documentation change was made. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>