< bitcoin-git>
[bitcoin] practicalswift opened pull request #16033: Hold cs_main when reading chainActive via getTipLocator(). Remove assumeLocked(). (master...assumeLocked) https://github.com/bitcoin/bitcoin/pull/16033
< fanquake>
wumpus I think #15968 is mergable, not sure if it'll get another BSD ack
< bitcoin-git>
[bitcoin] practicalswift opened pull request #16034: Add assertion to make sure the LockAnnotation guarantees we give are truthful (ifdef DEBUG_LOCKORDER) (master...make-sure-LockAnnotation-promises-are-truthful) https://github.com/bitcoin/bitcoin/pull/16034
< bitcoin-git>
bitcoin/master fa7e311 MarcoFalke: [doc] rpcwallet: Only fail rescan when blocks have been pruned
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #15870: wallet: Only fail rescan when blocks have actually been pruned (master...1904-walletRescanPruned) https://github.com/bitcoin/bitcoin/pull/15870
< bitcoin-git>
bitcoin/master 41ab2a8 orient: fix static_assert for macro HAVE_THREAD_LOCAL
< bitcoin-git>
bitcoin/master 8f2f17f Wladimir J. van der Laan: Merge #15970: Utils and libraries: fix static_assert for macro HAVE_THREAD...
< bitcoin-git>
[bitcoin] laanwj merged pull request #15970: Utils and libraries: fix static_assert for macro HAVE_THREAD_LOCAL (master...master) https://github.com/bitcoin/bitcoin/pull/15970
< bitcoin-git>
[bitcoin] promag opened pull request #16037: rpc: Fail importwallet only if a required block is pruned (master...2019-05-importwallet-pruned) https://github.com/bitcoin/bitcoin/pull/16037
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu May 16 19:00:37 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< kanzure>
small topic but doesn't need much discussion: topic collection for upcoming physical meeting. please send me your ideas or what you want to hear from someone else. it's voluntary.
< wumpus>
nothing on moneyball 's list i see
< aj>
hey
< meshcollider>
hi
< jnewbery>
hi
< luke-jr>
hi
< wumpus>
#action send topics for upcoming physical meeting to @kanzure
< dongcarl>
Any way to participate in physical meeting if we’re not there physically?
< wumpus>
although there's now two PRs by sipa in there
< wumpus>
but if no one has a problem with that, we'll just keep it like that
< wumpus>
any other topics?
< gmaxwell>
wumpus: I think the limit is (or should be) nominator, unless its resulting in getting not enough attention from the author.
< jonasschnelli>
Yes
< gmaxwell>
(unless you disagree, -- in which case we could hold off on my nom. no feelings hurt)
< jamesob>
gmaxwell: agree
< wumpus>
gmaxwell: I don't mind, it's not like a lot of things have been proposed in any case
< aj>
gmaxwell: it's just hard to keep track of who nominated with the github ui
< gmaxwell>
wumpus: right.
< meshcollider>
Yes I think we talked about that a week or two ago
< gmaxwell>
aj: it also doesn't really matter if someone messes up and noms two things. If someone starts doing it a lot it'll get noticed and we could track with some greppable IRC line or something. :)
< wumpus>
yes, would be nice if the 'card system' in projects allowed adding some extra text
< luke-jr>
could just not worry about limits until it gets crowded..
< gmaxwell>
I mean we could add tags for each regular contributor to track their nominations.
< gmaxwell>
but yeah, my though is wait for a problem.
< wumpus>
right
< jnewbery>
it's not clear to me whether high-priority is just for PRs blocking other stuff or not
< wumpus>
okay, anthing else to discuss?
< wumpus>
jnewbery: it's supposed to be for that, but if you have another reason why something is high priority, that works too imo
< wumpus>
it's good to have an overview of the work going on that has agreement that it's more high priority in the meeting, with zilions of refactoring PRs
< wumpus>
ok...
< * luke-jr>
pokes a cricket
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu May 16 19:20:25 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< wumpus>
it's the start of the 0.19 merge window, so things aren't crowded yet, they only get so closer to the release, so it's pretty smart to propose things for review now
< aj>
gmaxwell: do you have a minute to chat about #15502? i had a look into the "drop the threads and make it async". at the moment the netbase stuff relies on sync behaviour for connecting, so it becomes a bit intrusive
< aj>
gmaxwell: anyway the question is if there's any clever way of converting to async without being so intrusive, or if not, whether or not an intrusive change there still seems worthwhile?
< gmaxwell>
:-/
< aj>
gmaxwell: (connecting to the proxy for tor and similar is the main bit, which then needs a state machine, and blahblah)
< gmaxwell>
It's not just intrusive, adding 4 threads is a really non-trivial amount of additional VIRT (and probably that number should be equal to the number of needed outbound connections).
< gmaxwell>
I don't think the change itself as you have it is all that intrusive.
< gmaxwell>
but also it's not so non-intrusive that I feel like saying "Yeah this isnt the right way to do it long term but lets just do this for now."
< aj>
gmaxwell: sorry; i mean switching the change over from adding 4 threads to adding 0 or subtracting 1 by doing the connection stuff with poll/select asynchronously starts getting intrusive into netbase
< aj>
gmaxwell: making netbase.cpp:Socks5 not wait synchronously eg means turning the function inside out into a switch() state machine or something, i think
< gmaxwell>
hm. what about not doing this for socks? (though TBH socks needs it even more than non-socks...)
< aj>
gmaxwell: then it wouldn't work for tor-only nodes and stuff? that seems sucky?
< aj>
gmaxwell: the answer's probably "try it out and we'll see what it looks like" but it looks more messy than i was willing to start on my own without talking it through with someone
< gmaxwell>
Well progress is progress.
< gmaxwell>
It's a useful improvement that we really should get.
< gmaxwell>
ignoring implemenetation, I think ideally for every 'group' of outbound connections (right now automatic and addnode will be the only group but sdaftuar's PR will end up making blocksonly ones a group as well) should make all of its outstanding connections at once. ... since thats the most you can do without risk of ending up with too many.
< aj>
do you make outgoing blocksonly connections?
< gmaxwell>
aj: yes. but also thats what sdaftuar does, it adds additional blocksonly connections to nodes.
< aj>
but yeah, that aside, that makes sense and is nicely simple. start a bunch of connections; then when they timeout or whatever retry or replace them as appropriate
< gmaxwell>
right. it would be great in a threaded model, just every time you come around to the connect loop, and find you have free connections > threads, open a new thread.
< gmaxwell>
s/a/as many as needed/
< bitcoin-git>
[bitcoin] benthecarman closed pull request #15157: rpc: Bumpfee units change, satoshis to BTC (master...wallet_total_fee_units_change) https://github.com/bitcoin/bitcoin/pull/15157