Skip to content

Potential error in wait #112

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.

Sign up for GitHub

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

Jump to bottom
Open
drewdzzz opened this issue Feb 12, 2025 · 0 comments · May be fixed by #131
Open

Potential error in wait #112

drewdzzz opened this issue Feb 12, 2025 · 0 comments · May be fixed by #131
Assignees
@drewdzzz

Comments

@drewdzzz
Copy link
Collaborator

drewdzzz commented Feb 12, 2025 •
edited
Loading

When processing response, we don't add it to the map of futures.

After that, we wait for the future to appear in the map in wait. So, if result is not NULL, we actually wait until the timer is expired.

Also, result can be used for any future, not only requested one.
drewdzzz added a commit to drewdzzz/tntcxx that referenced this issue Apr 23, 2025
@drewdzzz
client: handle result argument of wait properly
d6e91aa 
Method `wait` of `Connector` allows to obtain result directly with
`result` argument - it can be useful when the user cares about
performance and don't want to perform an unneeded insertion to a map of
ready futures. However, we check that the future is ready by looking to
the map of ready futures, and the future is not inserted there when the
argument is used. The commit fixes the problem by checking the argument
as well.

Part of tarantool#112
drewdzzz added a commit to drewdzzz/tntcxx that referenced this issue Apr 23, 2025
@drewdzzz
client: return requested future with result argument of wait
0b0a970 
Currently, the argument returns any decoded future - that is
inconvenient and completely unusable. Let's return only the requested
future, or nothing, if it's not ready.

Closes tarantool#112
drewdzzz added a commit to drewdzzz/tntcxx that referenced this issue Apr 23, 2025
@drewdzzz
client: handle result argument of wait properly
c9f3dde 
Method `wait` of `Connector` allows to obtain result directly with
`result` argument - it can be useful when the user cares about
performance and don't want to perform an unneeded insertion to a map of
ready futures. However, we check that the future is ready by looking to
the map of ready futures, and the future is not inserted there when the
argument is used. The commit fixes the problem by checking the argument
as well.

Part of tarantool#112
drewdzzz added a commit to drewdzzz/tntcxx that referenced this issue Apr 23, 2025
@drewdzzz
client: return requested future with result argument of wait
a103995 
Currently, the argument returns any decoded future - that is
inconvenient and completely unusable. Let's return only the requested
future, or nothing, if it's not ready.

Closes tarantool#112
drewdzzz added a commit to drewdzzz/tntcxx that referenced this issue Apr 23, 2025
@drewdzzz
client: handle result argument of wait properly
e379244 
Method `wait` of `Connector` allows to obtain result directly with
`result` argument - it can be useful when the user cares about
performance and don't want to perform an unneeded insertion to a map of
ready futures. However, we check that the future is ready by looking to
the map of ready futures, and the future is not inserted there when the
argument is used. The commit fixes the problem by checking the argument
as well.

Part of tarantool#112
drewdzzz added a commit to drewdzzz/tntcxx that referenced this issue Apr 23, 2025
@drewdzzz
client: return requested future with result argument of wait
f9d5a42 
Currently, the argument returns any decoded future - that is
inconvenient and completely unusable. Let's return only the requested
future, or nothing, if it's not ready.

Closes tarantool#112
drewdzzz added a commit to drewdzzz/tntcxx that referenced this issue Apr 24, 2025
@drewdzzz
client: handle result argument of wait properly
03d86c4 
Method `wait` of `Connector` allows to obtain result directly with
`result` argument - it can be useful when the user cares about
performance and don't want to perform an unneeded insertion to a map of
ready futures. However, we check that the future is ready by looking to
the map of ready futures, and the future is not inserted there when the
argument is used. The commit fixes the problem by checking the argument
as well.

Part of tarantool#112
drewdzzz added a commit to drewdzzz/tntcxx that referenced this issue Apr 24, 2025
@drewdzzz
client: return requested future with result argument of wait
d7df387 
Currently, the argument returns any decoded future - that is
inconvenient and completely unusable. Let's return only the requested
future, or nothing, if it's not ready.

Closes tarantool#112
drewdzzz added a commit to drewdzzz/tntcxx that referenced this issue Apr 24, 2025
@drewdzzz
client: return requested future with result argument of wait
abbe0c2 
Currently, the argument returns any decoded future - that is
inconvenient and completely unusable. Let's return only the requested
future, or nothing, if it's not ready.

Along the way, reformat argument list of modified functions to make them
conform clang-format.

Closes tarantool#112
@drewdzzz drewdzzz linked a pull request Apr 24, 2025 that will close this issue
Open
drewdzzz added a commit to drewdzzz/tntcxx that referenced this issue Apr 24, 2025
@drewdzzz
client: handle result argument of wait properly
03968dc 
Method `wait` of `Connector` allows to obtain result directly with
`result` argument - it can be useful when the user cares about
performance and don't want to perform an unneeded insertion to a map of
ready futures. However, we check that the future is ready by looking to
the map of ready futures, and the future is not inserted there when the
argument is used. The commit fixes the problem by checking the argument
as well.

Part of tarantool#112
drewdzzz added a commit to drewdzzz/tntcxx that referenced this issue Apr 24, 2025
@drewdzzz
client: return requested future with result argument of wait
3c7f774 
Currently, the argument returns any decoded future - that is
inconvenient and completely unusable. Let's return only the requested
future, or nothing, if it's not ready.

Along the way, reformat argument list of modified functions to make them
conform clang-format.

Closes tarantool#112
drewdzzz added a commit to drewdzzz/tntcxx that referenced this issue Apr 24, 2025
@drewdzzz
client: handle result argument of wait properly
00f1a67 
Method `wait` of `Connector` allows to obtain result directly with
`result` argument - it can be useful when the user cares about
performance and don't want to perform an unneeded insertion to a map of
ready futures. However, we check that the future is ready by looking to
the map of ready futures, and the future is not inserted there when the
argument is used. The commit fixes the problem by checking the argument
as well.

Also, the commit handles a situation when user waits for already decoded
future using `result` argument. Before the commit, `wait` would return
zero return code (success) but the `result` wouldn't be set - user still
had to check if it's not in the map of futures. After the commit,
already decoded future is moved to `result` as well, so if the function
returns successfully, `result` is guaranteed to be set.

Part of tarantool#112
drewdzzz added a commit to drewdzzz/tntcxx that referenced this issue Apr 24, 2025
@drewdzzz
client: return requested future with result argument of wait
2d9d6cc 
Currently, the argument returns any decoded future - that is
inconvenient and completely unusable. Let's return only the requested
future, or nothing, if it's not ready.

Along the way, reformat argument list of modified functions to make them
conform clang-format.

Closes tarantool#112
drewdzzz added a commit to drewdzzz/tntcxx that referenced this issue Apr 24, 2025
@drewdzzz
client: handle result argument of wait properly
2dbe527 
Method `wait` of `Connector` allows to obtain result directly with
`result` argument - it can be useful when the user cares about
performance and don't want to perform an unneeded insertion to a map of
ready futures. However, we check that the future is ready by looking to
the map of ready futures, and the future is not inserted there when the
argument is used. The commit fixes the problem by checking the argument
as well.

Also, the commit handles a situation when user waits for already decoded
future using `result` argument. Before the commit, `wait` would return
zero return code (success) but the `result` wouldn't be set - user still
had to check if it's not in the map of futures. After the commit,
already decoded future is moved to `result` as well, so if the function
returns successfully, `result` is guaranteed to be set.

Part of tarantool#112
drewdzzz added a commit to drewdzzz/tntcxx that referenced this issue Apr 24, 2025
@drewdzzz
client: return requested future with result argument of wait
995d5ec 
Currently, the argument returns any decoded future - that is
inconvenient and completely unusable. Let's return only the requested
future, or nothing, if it's not ready.

Along the way, reformat argument list of modified functions to make them
conform clang-format.

Closes tarantool#112
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@drewdzzz drewdzzz

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

client: fix result argument of wait drewdzzz/tntcxx
1 participant
@drewdzzz