Skip to content

rpc: persist the latest setgenerate state with ForceSetArg (#448)#454

Open
JSanchezFDZ wants to merge 1 commit into
Raptor3um:developfrom
JSanchezFDZ:fix/setgenerate-persist-genproclimit
Open

rpc: persist the latest setgenerate state with ForceSetArg (#448)#454
JSanchezFDZ wants to merge 1 commit into
Raptor3um:developfrom
JSanchezFDZ:fix/setgenerate-persist-genproclimit

Conversation

@JSanchezFDZ

Copy link
Copy Markdown

Follow-up to #448 / #449.

setgenerate stored -gen and -genproclimit with SoftSetArg(), which
only writes an arg when it is currently unset. Once the first
setgenerate call ran, those values were locked in: a later
setgenerate true 20 or setgenerate false could no longer update the
stored thread count, so the node kept reporting/using the count from the
very first invocation.

Since setgenerate is an explicit runtime command it must overwrite the
previous state, so this switches the two calls to ForceSetArg().

This is orthogonal to #449 (which corrects the response text) and touches
different lines — together they fully resolve the stale thread count
reported in #448.

…#448)

setgenerate stored -gen/-genproclimit with SoftSetArg(), which only writes
an arg when it is currently unset. After the first call the values were
locked in, so a later "setgenerate true 20" (or "setgenerate false") could
not update the stored thread count and the node kept reporting/using the
count from the first invocation.

setgenerate is an explicit runtime command and must win, so force the
values instead. This complements PR Raptor3um#449, which fixes the response text;
together they fully resolve the stale thread count in Raptor3um#448.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant