2020-05-15 19:26:19
asciilifeform: http://logs.nosuchlabs.com/log/therealbitcoin/2020-05-15#1000138 << btw i notice the wedge pill aint in there. may be 1 reason why jfw's box can't sync .
snsabot: Logged on 2020-05-15 14:09:11 jfw: I've read or at least skimmed all the vpatches ftr, signed & hosted at http://fixpoint.welshcomputing.com/v/bitcoin/
...

jfw: http://logs.nosuchlabs.com/log/therealbitcoin/2020-05-15#1000235 - from mod6's article I got the idea that his was still a halfway-fix, and yours still flagged experimental. I thought I'd wait for a finished thing before digging into it. Did I miss such a thing?
jfw: don't think the 'wedge' is afflicting me though, RPC remains responsive.
...

asciilifeform: http://logs.nosuchlabs.com/log/therealbitcoin/2020-05-16#1000278 << this is half-correct : the patch asciilifeform & mod6 baked, caps the mass of reply to 'getdata' for blox, but not tx. but thus far no one has observed a wedge powered by requesting mempool tx ( both asciilifeform and mod6 tried to make one artificially, and mod6 iirc wrote a debug log parser to look for 'heavy' tx, to throw in 'wedger' . )
snsabot: Logged on 2020-05-16 14:12:41 jfw: http://logs.nosuchlabs.com/log/therealbitcoin/2020-05-15#1000235 - from mod6's article I got the idea that his was still a halfway-fix, and yours still flagged experimental. I thought I'd wait for a finished thing before digging into it. Did I miss such a thing?
asciilifeform: ( 100% proper patch would cap both. but neither of us at the time was immediately able to figure out how to use the internal knobs to determine tx mass )
...

jfw: asciilifeform: hm, ok.

So then, mind sharing either here or, preferably, in some blog articles, just who you might be ?

If you find it worthwile, see my chat history. A couple of possibly interesting shortcuts: a micro self-intro, and a mini-review.

In summary and addition, I'm a Finn, with a personal interest in dependable tech (while not implying any kind of proficiency in the field). When I was a kid, dad explained to me how a carpenter may choose to build not the best wooden spoon he can, but one that wears out, or breaks in time -- just to stay in business. I don't know why, but this idea has bothered me ever since. It sounds cheating to me. And of course, the whole world somehow seems to be built on this exact principle.

And I fiddle with bitcoin, because I believe it's better for my future if it succeeds. Or, if not better for myself (say, I blow my chances somehow), I suppose better for the more honest people: perhaps a non-cheating carpenter.

I meant the BeginMessage()/EndMessage()/AbortMessage() composition, stuff your patches here replace.

Oh I see.

Do you mean the CRITICAL_BLOCK() macro? In what ways?

No, strictly what I wrote - the behavior of older versions of the code, as a whole, of which the locking is but one facet.

I'm not sure what you refer to there - something pre-0.5.3 ?

I meant the BeginMessage()/EndMessage()/AbortMessage() composition, stuff your patches here replace.

the old one was broken in however-many ways

Do you mean the CRITICAL_BLOCK() macro? In what ways?

I was apparently somehow still stuck in my head with the old composition of the code where the ENTER/LEAVE were necessary.

I'm not sure what you refer to there - something pre-0.5.3 ?

history-aware reader is doomed to answer those (annoying) questions anyway

I'm not sure about that either ; presumably it would depend on what he wants to know. If the goal is to verify that a new version has fully equivalent behavior to an old one then I can make it easy: it does not, because the old one was broken in however-many ways. What's more important not to change is the block validation rules (which is why I'm more cautious about ripping out e.g. BOOST_FOREACH) ; but even there to some extent we have to compare with the "ideal form" of "what was meant" because the original contained nondeterministic failure cases such as the BDB locks exhaustion business.

So I had already forgotten these macros were Satoshi's handwriting, and not Boost items, and was thinking "why bring in more Boost?" when asking my question.

Re: CRITICAL_BLOCK vs ENTER/LEAVE_CRITICAL_SECTION: I completely agree, I was apparently somehow still stuck in my head with the old composition of the code where the ENTER/LEAVE were necessary.

Re: CRITICAL_BLOCK implementation: history-aware reader is doomed to answer those (annoying) questions anyway, so in that sense, I don't see much gain.

Fwiw, I would've perhaps used the name "CRITICAL_SCOPE", for consistency.

The closer comparison would be to CRITICAL_BLOCK rather than ENTER/LEAVE_CRITICAL_SECTION. The main reasons to prefer the first to the second I'd say are that it leverages builtin language syntax and semantics, making for less code to keep track of (would you really prefer to malloc+free when stack allocation would suffice?), and that it does the right thing on nonlocal exits (eg return, goto, or exception being thrown which can happen in unexpected places).

Then compare CRITICAL_BLOCK with SCOPED_LOCK implementations and look at it from the other side: why on earth does the first involve an if-statement, wtf does a bare object evaluate to in boolean context, what's the scope of such an object declared inside the condition of such a statement, and how is it justified that the reader even has to ask these questions ?