-
-
Notifications
You must be signed in to change notification settings - Fork 25
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
Experimental async support (asyncio/trio/curio) #61
base: master
Are you sure you want to change the base?
Conversation
Extract code to be reused into an OSCBaseServer class move OSCThreadServer to its own module, inheriting from OSCBaseServer Create an OSCCurioServer and an OSCThreadServer to support async usage.
Sorry for hijacking this PR; I was wondering whether there are plans to add support for Trio and (Sadly enough, |
Trio has been added after i opened the PR, (as you can see in the server/trio_server.py and examples/trio_example.py files, about pure asyncio, i started something but it doesn’t work yet. edit: i had seen about anyio and considered maybe using it indeed (for now wanted to see how hard it was doing without), but if it doesn’t handle curio it’s less interesting. re-edit: also very interested in your feedback, i don’t have that much experience with asyncio/trio/curio, so if i’m pushing antipatterns, better know it sooner rather than later :). |
Oh, great, so there's a working Trio server already. Thanks, I haven't noticed that! I took a quick look at the code now. I'm not familiar with Curio so I can't comment on that part. As for Trio, the current implementation seems to run all message handlers in a separate task in a nursery, which is probably overkill for small synchronous handlers. I would create a memory channel with |
+ asyncio usage example + threadserver usage example + ensure we can stop all of them TODO: - cleanup the api, make sure difference between the servers are justified - TEST
ead80f8
to
eee1cda
Compare
Supports Curio, Trio and asyncio.