<vasild>
I guess this is the most straight-forward way, but that mutex would have to be acquired every time data is sent or received to/from the network and also when the rpc is called, I don't like this so much.
brunoerg has joined #bitcoin-core-dev
b_101 has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 248 seconds]
brunoerg has quit [Ping timeout: 256 seconds]
brunoerg has joined #bitcoin-core-dev
b_101 has joined #bitcoin-core-dev
cotsuka has quit [Ping timeout: 248 seconds]
b_101 has quit [Ping timeout: 260 seconds]
AaronvanW has joined #bitcoin-core-dev
cotsuka has joined #bitcoin-core-dev
b_101 has joined #bitcoin-core-dev
SpellChecker has quit [Ping timeout: 255 seconds]
b_101 has quit [Ping timeout: 264 seconds]
ghost43_ has joined #bitcoin-core-dev
ghost43 has quit [Ping timeout: 255 seconds]
bitdex has quit [Ping timeout: 255 seconds]
SpellChecker has joined #bitcoin-core-dev
bitdex has joined #bitcoin-core-dev
b_101 has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 256 seconds]
gnaf has quit [Quit: Konversation terminated!]
b_101 has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 252 seconds]
ziggie has joined #bitcoin-core-dev
brunoerg has quit []
b_101 has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 260 seconds]
AaronvanW has quit [Remote host closed the connection]
b_101 has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 256 seconds]
b_101 has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
bitdex has quit [Quit: = ""]
b_101 has quit [Ping timeout: 256 seconds]
b_101 has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 260 seconds]
SpellChecker has quit [Ping timeout: 255 seconds]
jtraub91 has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
SpellChecker has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
stacie_ has quit []
stacie_ has joined #bitcoin-core-dev
Guest16 has joined #bitcoin-core-dev
stacie_ has left #bitcoin-core-dev [#bitcoin-core-dev]
stacie has joined #bitcoin-core-dev
<stacie>
vasild: that is a good point about the mutex. That hadn't crossed my mind. A map of maps was on my list of potential ideas, but I am leaning more towards a single map. I would make a struct for the keys. That struct would have a field for connection type, direction, message type, etc. The values in the map would be another struct, with fields for bytes and message count.
jtraub91 has quit [Ping timeout: 246 seconds]
jtraub91 has joined #bitcoin-core-dev
<vasild>
stacie: "That struct would have a field for connection type, ..." -- What would be the type of the field?
andrewtoth_ has quit [Remote host closed the connection]
andrewtoth_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
<stacie>
vasild: I could be mistaken but I think there might be enums for most of these things? For example, the ConnectionType enum in src/node/connection_types.h. I will admit this new RPC is pushing the limits of both my C++ and Bitcoin Core knowledge :)
<vasild>
stacie: the proposal in the OP was good first issue, but maybe the evolved one, not so much :-D
<vasild>
so something like struct Key { ConnectionType conn_type; ... }
<vasild>
and then query the map like map[Key{.conn_type = Inbound, .msgtype = "inv", ...}].bytes
<vasild>
is this what you meant?
<lightlike>
vasild: "I don't like this so much." Just out of interest, do you have an idea for a solution that wouldn't require taking a lock (an potentially stall net a little bit) when querying the RPC?
<vasild>
lightlike: given that all those numbers need not be consistent, a pile of atomic integers that are loaded one by one and filled into the rpc reponse should do it
<vasild>
... or do they (need to be consistent)? I think it is ok if they are not
<vasild>
I mean lets say there is a response like: "sent_bytes_for_inv: 123128, sent_bytes_for_tx: 348736" -- is it ok if such an exact state never existed. E.g. what has happened is that 123128 was read, at that time the other number was 348700 but by the time the second number was read it got increased with 36 to 348736.
<lightlike>
vasild: if the inconsistencies are obvious they might confuse users, e.g. if the rpc says we sent more VERACKs than VERSIONs, which should never be the case.
yanmaani1 has quit [Remote host closed the connection]
yanmaani1 has joined #bitcoin-core-dev
andrewtoth_ has quit [Remote host closed the connection]
andrewtoth_ has joined #bitcoin-core-dev
<stacie>
vasild: yes! that struct example you posted ~1 hr ago is in line with what I was thinking. I had a TODO item to see how I could access the values (basically to fill in some C++ knowledge gaps), and what you posted makes sense to me
<pinheadmz>
any recco's for installing bitcoin core in a github CI action? trying wget bitcoincore.org now, takes like 10 minutes just to download
<darosior>
pinheadmz: can't you have some sort of cache?
<pinheadmz>
yeah there is a github action for caching depepndencies, Ill try that
<pinheadmz>
sometimes it downloads in 1.2 seconds. other times, 7 minutes ... ?!
Cory has quit [Changing host]
Cory has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] AaronDewes opened pull request #26674: Add reindex=auto flag to automatically reindex corrupt data (master...auto-recovery) https://github.com/bitcoin/bitcoin/pull/26674
AaronvanW has quit [Read error: Connection reset by peer]
<vasild>
stacie: ok
<vasild>
stacie: lightlike: I have to think a bit more if this can be done in some lock free manner without getting too complicated and about whether inconsistencies are ok or just go with a mutex. I guess the mutex is ok for now, but if/when networking becomes multi-threaded then those counters could become more of a problem
<vasild>
(if done with a mutex)
b_101 has joined #bitcoin-core-dev
<stacie>
vasild: that sounds good, thanks for pointing out this concern and keeping an eye on it. On the topic of potential inconsistencies, it was pointed out that one of the reasons to always return the sent/received direction together was to spare the user from any inconsistencies that could happen if you return sent totals in one call, and received totals in another.
<stacie>
I guess what I'm trying to say is some effort is being put into preventing inconsistencies, but I don't know where it is appropriate to draw the line, and at what cost. All of which goes to what you pointed out about the mutex
b_101 has quit [Ping timeout: 248 seconds]
bomb-on has quit [Quit: aллилѹіа!]
AaronvanW has joined #bitcoin-core-dev
Talkless has quit [Ping timeout: 256 seconds]
test__ is now known as _flood
AaronvanW has quit [Ping timeout: 268 seconds]
<bitcoin-git>
[bitcoin] john-moffett opened pull request #26675: wallet: For feebump, ignore abandoned descendant spends (master...2022_12_Bumpfee_ignore_abandoned) https://github.com/bitcoin/bitcoin/pull/26675
yanmaani1 has quit [Remote host closed the connection]
yanmaani1 has joined #bitcoin-core-dev
asoltys has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
brunoerg has quit []
andrewtoth_ has quit [Remote host closed the connection]
AaronvanW has quit [Ping timeout: 252 seconds]
Zenton has quit [Ping timeout: 260 seconds]
b_101 has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 256 seconds]
vasild has quit [Ping timeout: 255 seconds]
vasild has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] achow101 opened pull request #26679: wallet: Skip rescanning if wallet is more recent than tip (master...skip-newer-wallet-rescan) https://github.com/bitcoin/bitcoin/pull/26679
nanotube has quit [Ping timeout: 252 seconds]
jtraub91 has quit [Ping timeout: 252 seconds]
andrewtoth_ has joined #bitcoin-core-dev
andrewtoth_ has quit [Remote host closed the connection]
andrewtoth_ has joined #bitcoin-core-dev
andrewtoth_ has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-core-dev
andrewtoth_ has joined #bitcoin-core-dev
luke-jr has quit [Ping timeout: 260 seconds]
Talkless has joined #bitcoin-core-dev
luke-jr has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 260 seconds]
luke-jr has quit [Read error: Connection reset by peer]
luke-jr has joined #bitcoin-core-dev
luke-jr has quit [Read error: Connection reset by peer]