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

Experimental async support (asyncio/trio/curio) #61

Open
wants to merge 8 commits into
base: master
Choose a base branch
from
Open

Conversation

tshirtman
Copy link
Member

@tshirtman tshirtman commented Jun 26, 2021

Supports Curio, Trio and asyncio.

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.
@ntamas
Copy link

ntamas commented Jun 30, 2021

Sorry for hijacking this PR; I was wondering whether there are plans to add support for Trio and asyncio in the near future, preferably by using anyio as an abstraction layer on top of them. I am surveying Python implementations of OSC clients as I need to add OSC support to a larger application that is already committed to using Trio as the main event loop. If there are no plans to support Trio in the near future on your own, would you accept a PR for a Trio-based OSC client class?

(Sadly enough, anyio would have been great to add support for Trio, asyncio and curio at the same time until the author of curio requested removing support for curio in anyio at version 3.0 so it looks like Curio needs to be handled separately).

@tshirtman
Copy link
Member Author

tshirtman commented Jun 30, 2021

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 :).

@ntamas
Copy link

ntamas commented Jun 30, 2021

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 open_memory_channel and spawn two tasks in the nursery: one that reads the socket in a loop and puts whatever it has received into the TX end of the memory channel, and another task that reads the RX end of the memory channel and calls the handler immediately, synchronously. The handler could then receive nursery.start_soon as an additional argument and it could spawn a new async task into the nursery if it is necessary (i.e. if the handler is expected to take a long time or if it is going to perform blocking I/O).

+ 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
@tshirtman tshirtman changed the title Experimental async support (curio) Experimental async support (asyncio/trio/curio) Jan 18, 2022
@tshirtman tshirtman force-pushed the async branch 14 times, most recently from ead80f8 to eee1cda Compare January 19, 2022 00:55
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.

2 participants