Rate limiting for micro:bit using TaskQueue #2024
Conversation
| * A task queue to track communication tasks sent over the socket. | ||
| * The bucket in this task queue holds 1 task at a time, and refills | ||
| * at a rate of 10 tasks per second, from a queue that holds at maximum | ||
| * 30 tasks. If more than 30 tasks are added to the task queue in a short |
There was a problem hiding this comment.
"from a queue that holds tasks with a maximum total cost of 30. Since most tasks have a cost of 1 this means the queue will generally have at most 30 tasks."
…delay resolution (i.e. displayText in microbit).
There was a problem hiding this comment.
LGTM! tested it in a few different ways (forever broadcast triggering a display random, multiple parallel forever stacks, doing that simultaneous with reading sensor values) and everything behaves as expected.
The max total cost of 30 makes it so you can get into a situation where queued messages will send for three seconds, but that seems fine- it's a reasonable compromise, and definitely an edge case (only occurs if you use the broadcast trick to send messages very fast and stop the stack by clicking it rather than using the stop button).
Resolves
Proposed Changes
Use the new TaskQueue utility to rate limit the hardware command sent over the Scratch Link socket to the microbit, to prevent trying to send too many commands at once and potentially lock up the peripheral or the browser, etc.
Test Coverage
Should test stacks that send many commands in a short period of time (e.g. broadcast > when I receive > forever display symbol)