< fanquake> sipa how long will your node be running the poll PR for?
< sipa> fanquake: until you kill it
< sipa> :)
< phantomcircuit> sipa, but it's not defining type?
< sipa> phantomcircuit: my guess is that in C++ you can't have the "struct" keyword there
< sipa> which is optional otherwise anyway
< phantomcircuit> sipa, oh which means i probably am aliasing it or something
< phantomcircuit> sipa, it's definitely not an efficient way of getting fd updates, but it follows the same pattern as select
< phantomcircuit> the changes should also make it easier to switch to another pattern
< phantomcircuit> sipa, introduced a constant to init.cpp MAX_FILE_DESCRIPTORS and set it to 1024
< phantomcircuit> although technically it's not fixed basically anywhere afaik
< gmaxwell> thats not a good name for it though, max sockets or something, since it's only going to limit the poll usage, not leveldb and whatnot.
< phantomcircuit> gmaxwell, estimated max file descriptors?
< gmaxwell> noo because we can use many more FDs for leveldb than sockets already...
< gmaxwell> just MAX_MAX_CONNECTIONS? :P
< phantomcircuit> i was doing
< phantomcircuit> for reference on linux systems the max number of fd's is typically 1024
< sipa> phantomcircuit: we already have code for trying to raise the number of fds, if i remember
< phantomcircuit> return nMinFD; // getrlimit failed, assume it's fine
< phantomcircuit> lol
< phantomcircuit> sipa, yeah i see it
< phantomcircuit> gmaxwell, opinions on changing the default max connections when using poll or on windows?
< wumpus> luke-jr: I know you're joking but it makes me think, I don't think I've heard heard of *anything* using QtNetwork, let alone hardened P2P code
< wumpus> phantomcircuit: I think we should still move to libevent at some point, but first things first, I suppose this refactoring will move in the right direction for that
< wumpus> the thing I'm most worried about, is the same when switching over the P2P layer to libevent: how can we test this enough to be confident enough to merge this, without running into random trouble for users or suddenly losing connectable nodes etc
< wumpus> I think the whitelisting was a good idea at least, it means we're not exposed to issues for platforms it hasn't been tested on
< phantomcircuit> wumpus, any opinion on setting the default maxconnections higher on systems with high limits
< phantomcircuit> the reason not to is that each connection uses memory
< phantomcircuit> (which reminds me we should have a -maxmemory flag that sets all the other ones)
< gmaxwell> because memory, and because there currently isn't a need... hosts aren't getting maxed out.
< stevenroose> gettxoutsetinfo reports on the totals about the utxo set, right? (about total value, f.e.)
< stevenroose> Does that mean that provably unspent outputs (like OP_RETURN) are not included?
< sipa> exactlyu
< sipa> *exactly
< phantomcircuit> stevenroose, probably unspendable*
< sipa> phantomcircuit: no, provably
< sipa> OP_RETURN outputs cannot be spent
< sipa> ah
< sipa> you're correcting the "unspent", not the "provably" :D
< phantomcircuit> derp
< phantomcircuit> i misspelled provably
< kabaum> probably unspendable = bernanke ascii art
< bitcoin-git> [bitcoin] practicalswift opened pull request #14706: Fix icc (Intel C++ compiler) warnings (master...icc) https://github.com/bitcoin/bitcoin/pull/14706
< phantomcircuit> gmaxwell, aight i wont touch that