[RFE] use binary instead of atom for lcnt lock name

[zzydxm]

We met an issue when using lcnt on a node with millions of active sockets. It has to create 2 atoms like 'esock.r[xxxxx]' for every socket, so that the lcnt is locking itself on the atom table.

This change makes the lcnt use binaries instead of atom as lock name to avoid this issue.

However, this change slows down the lcnt result processing and also makes it use a lot more memory. Just raising this PR for discussion.

[github-actions]

CT Test Results

    4 files    152 suites   51m 59s ⏱️
1 723 tests 1 673 ✅ 50 💤 0 ❌
2 448 runs  2 378 ✅ 70 💤 0 ❌

Results for commit 2dc1a68.

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

[bmk]

I will look into making it possible to simplifying the socket mutex names (from "esock.r[10]" to just esock.r").

[zzydxm]

can we add an id field to ErlDrvMutex_ and make MCREATE support 2 args? in that way we don't need to do
sprintf(buf, "esock.w[" SOCKET_FORMAT_STR "]", sock);
descP->writeMtx = MCREATE(buf);

[jhogberg]

If you’re referring to id as present in the lock counting output, no. It has to be an immediate, and we’re careful not to expose any distinction between immediates and boxed terms in the NIF and driver interfaces.

[michalmuskala]

One option could be to have esock.r as the "type" and then an integer for the name - but this would require changes to the API to support this.

[jhogberg]

One option could be to have esock.r as the "type" and then an integer for the name - but this would require changes to the API to support this.

That still leaks a difference between small and big integers. 😕

[michalmuskala]

I guess if the argument is limited to a small than we could guarantee it's an immediate across all runtimes, but the size could be quite limiting. Otherwise we'd need to document maximum allowed value for the integer - still not ideal

[zzydxm]

I will look into making it possible to simplifying the socket mutex names (from "esock.r[10]" to just esock.r").

Do you mean you will do some other changes or just remove the SOCKET_FORMAT_STR on mutex creation? I can do that

[bmk]

The solution I have now is that the "format" of the mutex name can be configured.
That is a 'verbose' format (as today) or a simplified format: Just the "esock.r":
--enable-esock-verbose-mtx-name | --disable-esock-verbose-mtx-name

[jhogberg]

I'm closing this PR as @bmk will fix the underlying issue.