Message326868
I use it to integrate a concurrent-based software (B) with an asyncio-based software (A).
(B) will undergo a massive refactoring to become asyncio-based in the future, but for now, I need to use it as-is.
I don't want to modify (A) to handle concurrent.futures.Future (it is developped by another team by the way) and I prefer to begin to implement asyncio into (B).
So (A) waits for a task request with an asyncio.Future, then processes it and populates the Future's result.
(B) has a waiting loop into a thread that handles multiples concurrent.futures.Future.
When (B) receives a request it creates a concurrent.futures.Future and push it into a queue for the waiting loop. If the request asks for a task implemented by (A), it wraps it into an asyncio.Future and call (A) with it.
(A) processes the task and populates the asyncio.Future's result. That's why I needed to implement the proposed behaviours.
Actually I will not need it for long, as (B) will become asyncio-based, but I wanted to integrate (A) and (B) with as less effort as possible, so I implemented my custom Future wrapper, but I think it is useful to refactor concurrent-based software to asyncio incrementally (and I will have to do it multiple times in the near future). |
|
Date |
User |
Action |
Args |
2018-10-02 08:41:46 | huji | set | recipients:
+ huji, asvetlov, yselivanov |
2018-10-02 08:41:46 | huji | set | messageid: <1538469706.04.0.545547206417.issue34430@psf.upfronthosting.co.za> |
2018-10-02 08:41:46 | huji | link | issue34430 messages |
2018-10-02 08:41:45 | huji | create | |
|