I’m currently re-writing my little asynchronous webserver project, growler, to support curio in addition to asyncio. I assume if this is successful, it wont be hard to support anything else that comes around. I’d also like it to be a model for writing non-trivial code that is flexible enough to support multiple ‘backends’.
I think I’ve hit a roadblock while trying to replace an
asyncio.Future. It was used as a placeholder for the incoming HTTP request’s body data, allowing the app to run while the (potentially large) body loads in the background. When the body is needed, awaiting this future would block until the full body is read in, resume.
I’m looking for a mechanism that can restart the execution of a waiting coroutine in a generic way. I’ll understand if this cannot be done. I’ve been trying various permutations of
send-ing data between coroutines and generators to no avail.
One option, though I hesitate to ask, is to add a special case for handling asyncio.Future objects in the curio Kernel. This is of course a bad idea for many reasons.