Symmetrical chaining futures in asyncio.future.wrap_future

[whuji]

BPO	34430
Nosy	@asvetlov, @1st1, @whuji
PRs	bpo-34430 Symmetrical chaining futures in asyncio.future.wrap_future #8807

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2019-04-03.08:45:32.122>
created_at = <Date 2018-08-18.11:02:20.130>
labels = ['type-feature', '3.8', 'expert-asyncio']
title = 'Symmetrical chaining futures in asyncio.future.wrap_future'
updated_at = <Date 2019-04-03.08:45:32.121>
user = 'https://github.com/whuji'

bugs.python.org fields:

activity = <Date 2019-04-03.08:45:32.121>
actor = 'huji'
assignee = 'none'
closed = True
closed_date = <Date 2019-04-03.08:45:32.122>
closer = 'huji'
components = ['asyncio']
creation = <Date 2018-08-18.11:02:20.130>
creator = 'huji'
dependencies = []
files = []
hgrepos = []
issue_num = 34430
keywords = ['patch']
message_count = 6.0
messages = ['323703', '323706', '323715', '326810', '326868', '339384']
nosy_count = 3.0
nosy_names = ['asvetlov', 'yselivanov', 'huji']
pr_nums = ['8807']
priority = 'normal'
resolution = 'wont fix'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue34430'
versions = ['Python 3.8']

[whuji]

asyncio.future.wrap_future is used to wrap a concurrent.future.Future in a asyncio.future.Future.

The actual implementation as the following behaviours :

1. When the concurrent.future.Future gets a result, the asyncio.future.Future gets the same result,
2. When the asyncio.future.Future is cancelled, the concurrent.future.Future is cancelled

I wonder why the futures synchronisation is not symmetrical ?
I propose to add the following behaviours :

3. When the asyncio.future.Future gets a result, the concurrent.future.Future gets the same result,
4. When the concurrent.future.Future is cancelled, the asyncio.future.Future is cancelled

I have also posted a request pull that implements the proposed behaviours, in case of acceptation.

If there is good reasons to not implement the proposed behaviours, I would be glad to know.

Thank you !

[whuji]

Actually the PR does not pass some tests, I will work on this. If the new behaviours are accepted, I will implement them soon.

[whuji]

The proposed solution (PR) has passed all tests.

[1st1]

The PR needs a very careful review, but in general I'm OK with the idea. I'm also curious why do you want to fix wrap_future -- how are you using it?

[whuji]

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

[whuji]

Can be closed if not needed by the community.