It’s very rare in OTP to have side-effects. I am just not used to them. But one that just bit me in the arse and made me take a tour of some source-code was: I didn’t expect a start routine (that returns `{ok, Pid}') to necessary also link my calling process to the spawned one.
Ought one assume that start routines come with the side-effect of linking the calling process 99 times of 100 – vs. just spawn a new process without linking? (I do use the word side-effect loosely. You know what I am driving at
Or prehaps: is there a good naming convention for a start routine that doesn’t link, that is used around Erlang companies?
I am a huge fan of answering my own questions on forums within 60 seconds of posting. It just occured to me that `start_link/n’ is the convention. It just isn’t the convention used in all of OTP. Eg. the tftp(3) application has start, that also links, and it threw me. Perhaps a dead corner of OTP, so nobody will care much.
As you already discovered, the convention in OTP is start vs start_link and one has to consciously choose which one to use depending on what you want (arguably the default should have been to always link, but the ship has already sailed for that ).
Under the hood, in Erlang you have these low level primitives:
spawn/X - spawns without link
spawn_link/X - spawns with link
spawn_monitor/X - spawns without link but with a monitor
spawn_opt/X which is the most generic form, that can get both linked and monitored
They are all atomic (meaning the linking/monitoring will happen exactly as the process is spawned you’ll be guaranteed to get all signals/messages to your parent process regardless of what happens with the process at startup).
