Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support tokio for platforms without multi-threading support #12

Closed
wants to merge 3 commits into from

Conversation

futursolo
Copy link
Member

@futursolo futursolo commented Dec 13, 2023

Description

@langyo

This pull request consists of the following changes:

  • Supports tokio for platforms without multi-threading support.

Checklist

  • I have self-reviewed and tested this pull request.
  • I have added tests for my changes.
  • I have updated docs to reflect any new features / changes in this pull request.
  • I have added my changes to CHANGELOG.md.

Copy link
Member

@hamza1311 hamza1311 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be nice to have tests for it, if none already test for this functionality

@futursolo
Copy link
Member Author

futursolo commented Dec 17, 2023

After some consideration, I think it is not possible to replicate the behaviour described in test test_spawn_local_within_send.
Since it is not possible to automatically register a LocalSet for tasks spawned by tokio::spawn to enable prokio::spawn_local when a task is not running in a dedicated prokio worker thread, This results in hard to explain behaviour and contradicts how prokio works with multi-threading support.

use prokio::Runtime;

let runtime = Runtime::default();

runtime.spawn_pinned(|| async {
    tokio::spawn(async {
        prokio::spawn_local(async {
            // Despite running within prokio runtime,
            // this does not work without dedicated worker thread.
        });
    });
});

For now, I think it is better to assume outside-runtime behaviour for prokio.
Where a LocalSet is explicitly required to use LocalServerRenderer.

Since most web frameworks in tokio uses Send futures, I do expect issues with most web frameworks.
However, the only way to solve this properly is to wait std::thread support for wasm32-wasi.

@futursolo futursolo closed this Dec 17, 2023
@langyo langyo mentioned this pull request Dec 21, 2023
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants