-
Notifications
You must be signed in to change notification settings - Fork 94
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
feat(ETH transport & heartbeats): various enhancements/features #2058
Conversation
fbf0dad
to
4663949
Compare
08c44d5
to
e39bede
Compare
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
ba35834
to
6973845
Compare
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
59b78de
to
d770af9
Compare
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
… into eth-ws-and-heartbeats
Signed-off-by: onur-ozkan <work@onurozkan.dev>
b2409d2
to
df48248
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Q: To get my thoughts straight, the websocket_transport.rs
implementation is thread safe because we get a new id (hashmap key) each time thus we will never access (read/write) the same key from two threads at the same time?
mm2src/coins/eth/eth_rpc.rs
Outdated
Web3Transport::Metamask(metamask) => metamask.execute(method, params.clone()), | ||
}; | ||
|
||
match execute_fut.timeout(Duration::from_secs(15)).await { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you define this 15
literal as a const instead? Also, isn't 15 a very long time :o
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made the Duration
constant altogether and used in EthCoin::get_live_client
and EthCoin::try_rpc_send
.
let response_map = unsafe { &mut *self.responses.0 }; | ||
let _ = response_map.insert(request_id, res_bytes); | ||
|
||
notifier.send(()).expect("receiver channel must be alive"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't this ever panic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. Caller is awaiting for the response through this channel. If it ever drop before that, we should panic as something def. going wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ahaa I was thinking this was a notifier for external communication (not us).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔥
Signed-off-by: onur-ozkan <work@onurozkan.dev>
That's part of it. Each request utilizes an atomic ID and only makes modifications using that ID. Additionally, we are waiting for notification from another thread to read and remove the key, ensuring that we don't attempt to read and delete it while another thread is attempting to write to it. This sequential computing is ensured via the thread channel notification. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sequential computing is ensured via the thread channel notification.
I get the point in that we process all the responses in a single worker thread, but don't we ever access the map from another thread (even with a different key)?
e.g. are we always sure ...
Signed-off-by: onur-ozkan <work@onurozkan.dev>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, Thanks!
Signed-off-by: onur-ozkan <work@onurozkan.dev>
8200379
to
537a020
Compare
* dev: feat(indexeddb): advanced cursor filtering impl (KomodoPlatform#2066) update dockerhub destination repository (KomodoPlatform#2082) feat(event streaming): configurable worker path, use SharedWorker (KomodoPlatform#2080) fix(hd_tests): fix test_hd_utxo_tx_history unit test (KomodoPlatform#2078) feat(network): improve efficiency of known peers handling (KomodoPlatform#2074) feat(nft): enable eth with non fungible tokens (KomodoPlatform#2049) feat(ETH transport & heartbeats): various enhancements/features (KomodoPlatform#2058)
REQUEST_TIMEOUT_AS_SEC
)web3
field from ETH coin[ ] Implementing and using(3c2313a)fn with_socket
for ETHCOIN_BALANCE
event