Skip to content

Conversation

@Vizonex
Copy link
Owner

@Vizonex Vizonex commented Jan 20, 2026

What do these changes do?

I had an idea about using libuv's thread-pool as a backup mechanism to help eliminate a few resource heavier elements such as the ThreadPoolExecutor that was originally utilized for the functions that I have now changed making it possible to do a few faster things when needing to lazily use a function like asyncio.to_thread(...) There are a few caveats such as not being able to control how many threads are spun up but this new implementation should be very minimal on resources and very beneficial.

I added in a test for this function to make sure it runs correctly but now there should no longer be a chain of 3 items before reaching the functions
Orgininally it was

asyncio.Future -> concurrent.futures.Future -> _WorkItem

Now it is setup this way making it a lot faster to reach.

asyncio.Future -> UVWork

Are there changes in behavior for the user?

Is it a substantial burden for the maintainers to support this?

Related issue number

fixes #111

Checklist

  • I think the code is well written
  • Unit tests for the changes exist
  • Documentation reflects the changes

@Vizonex Vizonex marked this pull request as draft January 20, 2026 23:26
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.

Optimization idea involving a UVWork class when there is no default executor.

2 participants