< jonasschnelli>
Maybe for test reasons it could make sense... although, even there we could inject a tmp file
< jonasschnelli>
(and get rid of the fFileBackend stuff)
< jonasschnelli>
Luke-Jr: background has now to tiffs,... but does not appear on my mac. Maybe a DSStore problem? Why did you change the DS_Store file anyway? Because of the icon position (based on the filename)?
< sdaftuar>
if anyone is up for reviewing 7062, it could use some review (one of last two PRs tagged for 0.12 that's not yet merged).
< desantis>
honest question: How does this channel differ from bitcoin-dev?
< sipa>
This is specifically about the Bitcoin Core software, and its implementation details
< sipa>
#bitcoin-dev is more for development of the protocol
< desantis>
sipa: thanks!
< sdaftuar>
why do blocks with more sigops than MAX_BLOCK_SIGOPS not get marked as failed (BLOCK_FAILED_VALID)?
< sipa>
sdaftuar: thry should!
< sdaftuar>
sipa: ah, good to know
< GitHub85>
[bitcoin] sdaftuar opened pull request #7217: Mark blocks with too many sigops as failed (master...fix-sigops-rejection) https://github.com/bitcoin/bitcoin/pull/7217
< job_>
BlueMatt gmaxwell good seeing you guys last night. a few quick questions about getblocktemplate when you've got a sec
< BlueMatt>
go for it
< jamesob>
i) what, in particular, about getblocktemplate requires holding cs_main? is it just that CreateNewBlock needs it, or do we want a consistent snapshot of the txs to include in the template?
< sipa>
yeah, consistent snapshot
< sipa>
and later verification of the constructed block
< sipa>
which needs access to the utxo set
< jamesob>
okay, so we need a consistent view of the utxo set to validate the block template we've just constructed
< jamesob>
ii) under what circumstances do we want to rebuild this blocktemplate cache we're talking about replacing the `CreateNewBlock` routine with?
< BlueMatt>
jamesob: yes, CreateNewBlock needs a consistent snapshot of the utxo
< BlueMatt>
so getblocktemplate shouldn't take cs_main, but CreateNewBlock will, ofc, have to
< jamesob>
e.g. on new chain tip, on new txs, periodically?
< jamesob>
or some/all of the above
< BlueMatt>
hmm? no, keep CreateNewBlock, just cache its output in a field that getblocktemplate reads from
< BlueMatt>
as for rebuilding, just call CreateNewBlock on a timer for now
< BlueMatt>
we can get smarter later :)
< jamesob>
right on
< jamesob>
so should we start with a PR that moves CreateNewBlock to a time-rebuilt cache, then iterate from there?
< BlueMatt>
and the timer can be aggressive as long as CreateNewBlock aggressively gives up cs_main and just fails when a new block is coming in
< BlueMatt>
I'd assume all three things from last night can fit into one pr
< BlueMatt>
I'd hope its not much code, though, again, I havent looked at it
< BlueMatt>
problem with moving CNB to a background-thread by itself is you end up with way more cs_main time :(
< jamesob>
it looks like there's gonna be some shuffling... might have to factor the innards of the rpc definition out into some separate bit that we can call from some scheduled routine
< jamesob>
BlueMatt yeah, that's what I was thinking...
< jamesob>
like, if we've got this thing acquiring cs_main on an aggressive regular schedule, that may cause MORE contention
< BlueMatt>
yea, I figured half of the rpc code would have to be moved out
< BlueMatt>
that wouldnt surprise me
< BlueMatt>
yup, hence the requirement to drop cs_main and fail mid-process if there is "important" contention (ie a new block came in)
< BlueMatt>
contention around cs_main for other things sucks, but doesnt matter too much to most users
< jamesob>
ah, right. is there some existing pattern for saying "hey, this is a low-prio lock acquisition, allow interrupts"?
< BlueMatt>
nope
< sipa>
a large portion of the cs_main locking is actually due to ProcessMessage/SendMessage, which don't actually need cs_main (they could get their own locks that lock node-specific data)
< BlueMatt>
(and dont go overengineering there, either, which would be easy to do)
< BlueMatt>
ahhhhh, scope creep
< jamesob>
heh
< BlueMatt>
this one is wayyyy too easy to scope-creep on
< jamesob>
don't worry, I'm just tryin' to hold onto my ass for now -- not going to go on any cosmic refactoring adventures ;)
< BlueMatt>
adding a global boolean called fAboutToLockCSMainForBlockProcessing sucks, but.....more than that is gonna lead to bike shedding
< jamesob>
so, I forget: your suggestion was to set fAboutToLock...=true once you're going to rebuild the cache, and drop out of the process if some other thread has set that flag to false, i.e. signifying that there's some more important op that needs that lock?
< BlueMatt>
no, set the flag to true in ProcessMessage or AcceptNewBlock or wherever cs_main is first locked for block acceptance (from RPC or net, you really need to check both)
< BlueMatt>
then CNB will poll that flag a bunch while its running, and if it sees it, bail out
< jamesob>
gotcha
< BlueMatt>
once you get cs_main for new block processing, you can then drop the flag and let the background CNB thread wait for its turn for cs_main
< sipa>
note that such a flag technically would require its own lock :)
< BlueMatt>
yup :(
< sipa>
or an atomic bool (but c++11 isn't quite there yet...)
< BlueMatt>
yea, this is muchhh nicer with atomics
< BlueMatt>
since atomic bool is guaranteed to be lock-free
< BlueMatt>
oops, no, sorry, atomic_flag is guaranteed, atomic_bool is not
< jamesob>
cool. iii) how do we want to handle this periodic rebuild; is this going to hook into the CScheduler abstraction somehow, or would we dedicate a whole new thread for it (which I doubt)?
< sipa>
use CScheduler
< jamesob>
roger
< jamesob>
good seeing you last night as well, sipa. hope you got some sleep :)