<jpk68:matrix.org> Is it just me, or is this a potential data race?

<jpk68:matrix.org> github.com/monero-project/monero/bl…rc/common/threadpool.h#L70C5-L71C55

<jpk68:matrix.org> error_flag can be read from multiple places and isn't atomic

.merge+ 10505

Added

jpk68 the flag is only ever changed from false to true, so it's safe. Some readers might miss an update if they read at the exact same time, but they will presumably see it next time the read the error flag.

.merge+ 10381

Added

.merge+ 10165

Added

.merge+ 10573

Added

^ adding before the 1 week deadline since this is just a resubmit with fixed indent

<jpk68:matrix.org> sech1: Thanks.

<rbrunner7> How do I get the Wallet API files to compile when building the Monero core software? I tried with setting "option(BUILD_GUI_DEPS "Build GUI dependencies." ON)" in the toplevel CMakeLists.txt file, but either that does not get evaluated, or is altogether the wrong approach ...

<rbrunner7> Maybe the problem is that I try all this with a debug build and not a release build?

IIRC... make -C wherever wallet2_api

or maybe wallet_api

or modify it in CMakeCache.txt

<silicon.dystopia:matrix.org> speaking from a user's perspective - how, if at all known atp, will transition to post-quantum cryptography work for just users?

<silicon.dystopia:matrix.org> if one buys a hardware wallet rn, will they have to buy a new one, because the hardware doesn't support post-quantum algorithms? [idk if it's implemented in the userspace or the instruction set]

<rbrunner7> Thanks, moneromooo, but it turned out taking the big hammer out with "make debug-test" also compiles this :)

<jpk68:matrix.org> @silicon.dystopia:matrix.org: Regarding hardware wallets specifically - there's nothing about PQ algorithms that would require a change in instruction set. Just like any change in the protocol, signing will have to be implemented in the hardware wallet firmware, so ultimately it is up to Ledger/Trezor whether or not you ha [... too long, see mrelay.p2pool.observer/e/v8T_4IELOWZBVFgz ]

<jpk68:matrix.org> Hopefully that's a correct-enough explanation. I assume migration to post-quantum outputs will work just like previous protocol upgrades (?)

<jpk68:matrix.org> Of course, the actual UX changes related to PQ crypto might be different, namely longer addresses/sync times and the like

.merges

10165 10381 10505 10517 10518 10568 10573

<jpk68:matrix.org> Shouldn't the riscv tag also be on 10570?