-
Notifications
You must be signed in to change notification settings - Fork 6
client: fix result
argument of wait
#131
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
Open
drewdzzz
wants to merge
4
commits into
tarantool:master
Choose a base branch
from
drewdzzz:wait_with_response
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
d7df387
to
abbe0c2
Compare
result
argumentresult
argument of wait
2d9d6cc
to
995d5ec
Compare
Ignoring clang-format suggestions in order not to mess with the diff. Suggestionsdiff --git a/src/Client/Connection.hpp b/src/Client/Connection.hpp
index d9626f0..30547e1 100644
--- a/src/Client/Connection.hpp
+++ b/src/Client/Connection.hpp
@@ -228,9 +228,8 @@ public:
friend
bool hasDataToDecode(Connection<B, N> &conn);
- template<class B, class N>
- friend
- enum DecodeStatus processResponse(Connection<B, N> &conn, int req_sync, Response<B> *result);
+ template <class B, class N>
+ friend enum DecodeStatus processResponse(Connection<B, N> &conn, int req_sync, Response<B> *result);
template<class B, class N>
friend
@@ -527,7 +526,7 @@ inputBufGC(Connection<BUFFER, NetProvider> &conn)
}
}
-template<class BUFFER, class NetProvider>
+template <class BUFFER, class NetProvider>
DecodeStatus
processResponse(Connection<BUFFER, NetProvider> &conn, int req_sync, Response<BUFFER> *result)
{
diff --git a/src/Client/Connector.hpp b/src/Client/Connector.hpp
index 863bd28..c0db86e 100644
--- a/src/Client/Connector.hpp
+++ b/src/Client/Connector.hpp
@@ -171,7 +171,7 @@ Connector<BUFFER, NetProvider>::close(ConnectionImpl<BUFFER, NetProvider> &conn)
m_NetProvider.close(conn.strm);
}
-template<class BUFFER, class NetProvider>
+template <class BUFFER, class NetProvider>
int
Connector<BUFFER, NetProvider>::connectionDecodeResponses(Connection<BUFFER, NetProvider> &conn, int req_sync,
Response<BUFFER> *result)
|
mkostoevr
approved these changes
Apr 24, 2025
Connector uses a special helper for decoding responses of ready-to-decode connections and then it erases them from `m_ReadyToDecode` set by himself. That's not a good design and it can lead to various bugs (there is already a bug, actually) because it's easy to forgot to erase a decoded connection. So let's move the erasure right to the `connectionDecodeResponses` helper. Note that the helper must be turned into a method of `Connector` since it needs to use its fields. The above-mentioned bug happens because we decode responses in `Connector::wait` right before the main loop but we forgot to remove the connection from `m_ReadyToDecode` set there. Closes tarantool#124
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
Somewhy we cast `nullptr` to the needed class when calling this function and it looks ugly. Let's simply set default value of `result` to `nullptr` not to pass it explicitly. Also, it will simplify the next commit - we will add another optional argument to this function.
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
995d5ec
to
2af6952
Compare
CuriousGeorgiy
approved these changes
May 5, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The argument was completely broken - the commit fixes it.
Along the way, fixed a crash when a decoded future appeared in
m_ReadyToDecode
. See the commits for details.Closes #112
Closes #124