Allow monitor options in proc_lib:start_monitor/5

[Maria-12648430]

Currently, the spawn options monitor and {monitor, MonitorOpts} are disallowed in the proc_lib:start* functions. This goes back all the way to R11, a ticket OTP-6345, and this post on the old Erlang ML.

For proc_lib:start_monitor, it makes no sense to forbid monitor options. Or at least, we don't see any benefit in doing so. On the contrary, it prevents "customizing" the monitor (eg custom tags, usage of the new priority option, etc). This PR removes this restriction.

For proc_lib:start and proc_lib:start_link, it would be possible to remove the restriction also, that is, without restoring the buggy behavior that seems to have given raise to OTP-6345.
However, in the presence of a monitor or {monitor, MonitorOpts} spawn option, the return value would change from Ret to {Ret, Mon}, with repercussions via gen into the start/start_link functions of the gen_* behaviors.
This may be ok, and require mostly work on the specs and documentation in the gen_* behaviors, aside from some adaptions in gen. The bigger question IMO is if and how supervisors should cope with this?

---

This PR also does a few more things than what is listed above, which are related to the new {link, LinkOpts} spawn option that appeared with the new priority messages. Those are mostly just documentation changes.

[github-actions]

CT Test Results

    4 files    221 suites   1h 55m 14s ⏱️
3 748 tests 3 644 ✅ 104 💤 0 ❌
4 795 runs  4 667 ✅ 128 💤 0 ❌

Results for commit d11e342.

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

[michalmuskala]

FWIW using [monitor, monitor] or [monitor, {monitor, Opts}] is just fine in spawn_opt so it might be fine to just add this option unconditionally

[Maria-12648430]

Yes, but which one of conflicting options (eg monitor vs {monitor, Opts}) wins is undocumented (currently, it is the last one in the list). So if we want to play strictly by the book ("what's not documented may change, at any time, without notice"), we need to check.

[Maria-12648430]

The type erlang:link_option/0 was not exported, but should be (like, erlang:monitor_option/0 is also exported). On the way, I improved the documentation there a little.

[Maria-12648430]

Btw @rickard-green @jhogberg this PR has been lying around for quite a while now, since May. Is there any interest in it?

[juhlig]

For proc_lib:start and proc_lib:start_link, it would be possible to remove the restriction also, that is, without restoring the buggy behavior that seems to have given raise to OTP-6345.
However, in the presence of a monitor or {monitor, MonitorOpts} spawn option, the return value would change from Ret to {Ret, Mon}, with repercussions via gen into the start/start_link functions of the gen_* behaviors.
This may be ok, and require mostly work on the specs and documentation in the gen_* behaviors, aside from some adaptions in gen. The bigger question IMO is if and how supervisors should cope with this?

I don't think supervisors need to handle this. It is the responsibility of the child start function to return something that the supervisor can handle.

That said, the child start function is executed in the context of the supervisor process, so if it sets up a monitor there one way or other, all this leads to is that the supervisor receives an unexpected message when the child exits.

About allowing monitor options in proc_lib:start and proc_lib:start_link, my opinion is divided. OTOH, I would say that there shouldn't be any such restrictions unless necessary. OTOH, all combinations are already possible (with this PR, even customization of monitors): if you want an unlinked, unmonitored process, use start. If you want a linked, unmonitored process, use start_link. If you want an unlinked, monitored process, use start_monitor. If you want a linked, monitored process, use start_monitor with a link option 🤷‍♂️