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

Добавить запуск Future с блокирующими операциями #21

Open
DragonFrai opened this issue Nov 9, 2023 · 1 comment
Labels
by design Issue has a conclusion defined the design of API futures Assigned with futures module

Comments

@DragonFrai
Copy link
Owner

DragonFrai commented Nov 9, 2023

Для Future обслуживающих ввод-вывод или производящих большое количество операций без смены контекста, следует добавить методы запуска на потоках (особые потоки планировщика или тредпул дотнета), которые не будут блокировать потоки планировщика и не будут мешать выполнению асинхронных Future.

Альтернативным, более сложным но более казуальным и красивым вариантом, будет автоматически переводить Future выполняющую долгую операцию на выделенный поток. Однако это будет плохо работать с планировщиками с конечным числом потоков, т.к. они должны будут неявно увеличивать свои потоки не своими потоками.

@DragonFrai DragonFrai added the futures Assigned with futures module label Nov 9, 2023
@DragonFrai
Copy link
Owner Author

DragonFrai commented Jun 1, 2024

Это желание было продиктовано Rust планировщиками Future. В отличие от dotnet у них нет какого-то основного пула потоков, к которому можно привязать блокирующую операцию, поэтому появляется естественное желание использовать планировщик Future для запуска синхронной работы в контексте Future.
Вероятно, планировщики Future не стоит об этом беспокоиться (по крайней мере в обязательном порядке). Он все еще имеет право определять долго блокирующие Future, и снижать их негативное влияние, но не более.

В случае необходимости, пользователю следует воспользоваться тредпулом дотнет или тредпулом того исполнителя Future, которым он пользуется. Этот вопрос не должен стоять перед Core API, но Core API следует сделать это решение возможным, если какой-то планировщик действительно может обслуживать эту ситуацию.

@DragonFrai DragonFrai added the by design Issue has a conclusion defined the design of API label Jun 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
by design Issue has a conclusion defined the design of API futures Assigned with futures module
Projects
None yet
Development

No branches or pull requests

1 participant