[jwrosewell]

Closes #154

Problem

The usage sharing element's background thread waited for each record with recv_timeout(take_timeout), and when the wait ran out it did nothing and waited again (share_usage_element.rs L872-L904). With ShareUsageConfigBuilder::take_timeout(Duration::ZERO) every wait returned at once, so the thread spun and used a whole processor core for as long as the element lived. With the default of 100 milliseconds it woke ten times a second for nothing.

The take timeout had no other effect, and each message held exactly the minimum entries per message. The .NET and Java elements use the take timeout once the minimum is queued, taking more entries until none arrives within it or the message holds twice the minimum (ShareUsageElement.cs L96-L100, ShareUsageElement.java L351-L359).

Change

• Below the minimum entries per message, the background thread waits for each record with recv, which has no time limit and returns an error only once the element has been dropped and every queued record has been received. An idle element therefore uses no processor time, whatever its take timeout.
• Once the message holds the minimum, the thread takes more records, waiting up to the take timeout for each, until none arrives in that time or the message holds twice the minimum, then sends it, as the .NET and Java elements do. A take timeout of zero takes only what is already queued.
• When the element is dropped, the thread sends what remains, even below the minimum, as before.
• The documentation of the take timeout, the minimum entries per message, the default take timeout constant and the module says so.
• A unit test, a_message_takes_up_to_twice_the_minimum_within_the_take_timeout, queues five records with a minimum of two and a long take timeout, and checks the messages hold four and then one.
• A new test binary, pipeline-engines-fiftyone/tests/idle_cpu.rs, leaves an element idle for a second with a take timeout of zero and of 100 milliseconds, and checks the process used less than 250 ms of processor time. It reads the process's processor time on Windows and Linux, and is not built elsewhere. It has a binary of its own so no other test's work is counted.

The first commit of this pull request made the take timeout do nothing and sent exactly the minimum. The second gives the take timeout the role it has in .NET and Java. The specification is being amended to describe that rule (51Degrees/specifications#56).

How it was verified

On Windows 11 with Rust 1.95.0. The new tests were first run against the base commit 9fe201e, with nothing else changed, using cargo test -p fiftyone-pipeline-core -p fiftyone-pipeline-engines-fiftyone --no-fail-fast -- --test-threads=1, and each failed as shown.

• The test binary idle_cpu.rs came after that run, so the failure was measured with a scratch test doing the same thing, an element left idle for two seconds. It used 1,953 ms of processor time with a take timeout of zero and 0 ms with the default of 100 ms.

With the change, rustfmt --check passes on the changed files. The workspace checks on a local merge of every pull request for 4.5.12 (cargo fmt --all -- --check, cargo clippy --workspace --all-targets -- -D warnings, cargo doc --workspace --no-deps with warnings denied, and cargo test --workspace with the Device Detection Lite and IP Intelligence ASN data files) are added here when they finish.

Behaviour that changes

• An idle element uses no processor time whatever its take timeout, where a take timeout of zero used a whole core.
• A message holds from the minimum entries per message to twice that number, where it held exactly the minimum. Once the minimum is queued, the message waits up to the take timeout for each further record, 100 milliseconds by default, before it is sent.

What remains

• The specification change, Say how a usage sharing message is filled, from the minimum to twice it specifications#56, for the rule this follows.