pm: Fix busy ticket queue loop

[yondonfu]

What does this pull request do? Explain your changes. (required)

This PR fixes a busy ticket queue loop that was causing CPU usage on any node that creates a ticket queue loop (either an O that is redeeming tickets on its own or a transactor that is running a ticket redeemer service) to spike to 100% as soon as the ticket queue loop is created (i.e. if SenderMonitor.MaxFloat() is called). The CPU spike would last until the SenderMonitor stops the ticket queue loop when it stops monitoring an address due to inactivity for a certain period of time.

Specific updates (required)

See commit history.

How did you test each of these updates (required)

Tested manually. Without this change, as soon as you connect an O to a transactor running a redeemer service (i.e. using the -redeemer flag), you can observe the CPU usage of the transactor spike to 100%. With this change, the CPU usage of the transactor in this setup does not spike. The same is true if you start an O that does standalone redemption.

Does this pull request close any open issues?

Fixes #1618

Checklist:

• README and other documentation updated
• Node runs in OSX and devenv
• All tests in ./test.sh pass

[kyriediculous]

Interesting.

So I guess an empty default doesn't mean "do nothing" until a new message is received and there appears to be a difference between that and blocking until a message is received ?

Change looks good to me 👍

[yondonfu]

So I guess an empty default doesn't mean "do nothing" until a new message is received and there appears to be a difference between that and blocking until a message is received ?

Yep. A default case in a switch statement will fire if no other case in the select statement fires first.

[kyriediculous]

I’m still not entirely sure how this causes 100% CPU load though as there is node code block to be executed. I imagined it would immediately finish and wait for the next iteration of the loop.

[yondonfu]

I’m still not entirely sure how this causes 100% CPU load though as there is node code block to be executed. I imagined it would immediately finish and wait for the next iteration of the loop.

The default statement would keep on firing and the loop would keep on running because at the next iteration the default statement would once again fire first. The loop wouldn't be doing anything, but it would take up CPU time that is forced to execute the loop iteration which could otherwise be doing something else.

[kyriediculous]

Gotcha ! Thanks for clarifying Op di 22 sep. 2020 om 20:14 schreef Yondon Fu <[email protected]>

…

I’m still not entirely sure how this causes 100% CPU load though as there is node code block to be executed. I imagined it would immediately finish and wait for the next iteration of the loop. The default statement would keep on firing and the loop would keep on running because at the next iteration the default statement would once again fire first. The loop wouldn't be doing anything, but it would take up CPU time that could otherwise be doing something else. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#1619 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFJZZWXHERMORN7WPFRCTQ3SHDSPPANCNFSM4RV7ZRNQ> .