Add persistent_term:put_new

[Benjamin-Philip]

This PR adds the persistent_term:put_new to conditionally add a key-value only if the key is new.

Closes #9681.

/cc @jhogberg.

[github-actions]

CT Test Results

    3 files    142 suites   49m 31s ⏱️
1 644 tests 1 586 ✅ 57 💤 1 ❌
2 365 runs  2 287 ✅ 77 💤 1 ❌

For more details on these failures, see this check.

Results for commit 8686210.

♻️ 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

[josevalim]

Instead of adding put_new, would it be more useful to add a has_key function that could be used in more cases? I recognize put_new has the benefit of being atomic but I assume that the value you need to store is likely expensive to compute anyway, so you want to check if the key exists before you do any work.

[Benjamin-Philip]

I think a has_key would be a good addition, but not as a replacement to put_new. Like you said put_new has the benefit of being atomic which enables one to "correctly" (in a formal sense) update parallely out of the box. See the linked issue for my use case.

You can define a rudimentary has_key already by setting Default in get/2 to undefined or some other more specific atom. Nevertheless, has_key would be faster and less error prone.

TLDR; I think we should add both functions.

[Benjamin-Philip]

@jhogberg, I think this PR is review ready now. Sorry about the delay - I was busy the past 2 weeks...

[Benjamin-Philip]

Rebased on master to fix merge conflicts.

[Benjamin-Philip]

@jhogberg, Any updates on this? Do you think you can squeeze it in OTP 28? Also, do you think has_key should be added (in another PR, of course) as @josevalim suggested?

[jhogberg]

@jhogberg, Any updates on this? Do you think you can squeeze it in OTP 28?

As mentioned in the issue, the window for 28 was closed before you opened it. It can be included in 28.1 at the very earliest.

The refactor I mentioned is coming along well. It's feature-complete and offers far better add/update/erase performance (so long as literal GC isn't triggered), but read performance on dynamic keys has taken a hit that is proving a bit annoying to get rid of (statically known keys are effectively free however). I'm confident it'll work out however, and am aiming for OTP 29.

Also, do you think has_key should be added (in another PR, of course) as @josevalim suggested?

I can't see why not, I'll add it to my refactored version.

[Benjamin-Philip]

It can be included in 28.1 at the very earliest.

When do you think 28.1 will be released?