CT Test Results

       3 files     125 suites   43m 59s ⏱️
1 500 tests 1 449 ✔️ 51 💤 0 ❌
1 812 runs  1 743 ✔️ 69 💤 0 ❌

Results for commit 349b244.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

• Complete CT logs (Download Logs)
• HTML Documentation (Download HTML Docs)
• Windows Installer

// Erlang/OTP Github Action Bot

I am interested in the same answers, would it be possible to document it in greater details?

I am interested in the same answers, would it be possible to document it in greater details?

When async_dist is enabled there is no hard limit on how much you can buffer which is the intention. Signals will be buffered without restrictions just as in the node local case. It is up to the implementer that use this functionality to ensure that the system does not consume an unlimited amount of memory, for example by implementing flow control.

I'm not sure exactly what you want documented in greater detail. I thought it was quite clear in the provided documentation.

@rickard-green If each process had its own memory limit as an offset in kilobytes on the distribution buffer busy limit the option could become more similar to max_heap_size (for distributed send memory consumption specific to the Erlang process). The default could be {async_dist, 0} (equivalent to what is currently {async_dist, false}) with {async_dist, true} becoming {async_dist, infinity}. If {async_dist, pos_integer()} was used an exit kill signal could kill the process if it was seen exceeding that distribution buffer busy limit. Using infinity for memory consumption can help make the decision more explicit because the developer is clearly agreeing to the potential for unbounded memory growth.

I can understand something similar may have already been discussed, but wanted to mention the idea in case it hasn't.

@okeuday Values of {async, Limit} where Limit /= infinity would just be another flavor of the same problematic semi asynchronous strategy as we already have. The point of this PR was to make it possible to utilize truly asynchronous signaling also in the distributed case.