You may also be interested in the BEAM Book (linked the scheduling chapter directly) if you want to know more about the internals.
Nicd
dimitarvp
You can have 1000 Elixir processes stuck in an infinite loop (or a very long network call), on a 4-core / 8-thread CPU. The other Elixir processes will still run fine.
Understand that Erlang VM’s parallelism is not going to get deadlocked by a few rogue processes. That’s what makes it different and so desirable.
1
josefrichter
Yeah I was just watching Sasa’s talk linked above . It seems like the piece I was missing was the preemtive scheduling where one rogue process cannot really clog the cpu. It might be coming back over and over again in some cases, maxing out the CPU, but it can never take over and block the other processes. That’s fascinating!
1
dimitarvp
Yes. Without the preemptive scheduling of the runtime and the 99% transparent parallelism, Erlang / Elixir would remain just some curiosity languages and I personally would not use them.
As I said in other threads: don’t “love a language”. Do love the language’s runtime and (NOT in the case of Erlang and Elixir) compilation strictness (OCaml and Rust shine here).
The language syntax does not matter one bit. There are other pretty nice and solid frameworks out there – PHP’s Laravel is one very good example – but without a proper runtime and/or good compilation-level enforcement they still remain mostly curiosities, at least to serious programmers.
(And yes I am aware PHP and Ruby are used much more than Elixir. That’s a topic that’s beaten to death many times over but TL;DR no, that does not make them good. That makes them a safe choice for many employers and employees. At the end of the day we are in the whole thing for money. Programming is not just a hobby after all.)
4
ScriptyScott
Thanks all for the great resources! I come from a background of mobile development with a bit of web dev peppered throughout my career. I always found it strange how certain asynchronous task (sending emails, async calls, etc…) would require specifically calling the async version of the method and usually some sort of additional queue support, often complicating stacks with things like Redis. I’ve skimmed through some of the links posted here and it looks like Elixir/Erlang handles threading in a manner that’s reminiscent of some of the mobile platforms I’m used to. I’m really glad I asked this question, thank you so much for the resources will be taking a more in-depth look over the next few days.
2
softrage
Note that more generally, if you don’t want to wait for a long-running process to terminate, i.e. during an HTTP request, you can also easily spawn a new process. To be clear and to reiterate some info in this thread, these processes are very cheap: they are part of the Erlang Runtime System (ERTS), and are not OS processes, and are unrelated to the threads/cores available on the system. You can spawn a new process using one of the methods documented here. A simple example would be:
def some_route_handler(conn, _params) do
spawn(fn -> long_running_process() end)
send_resp(conn, 202, "Accepted")
end
Even though a synchronous operation won’t block execution for other users, it will of course for the current user waiting for that process, but spawning another process in this way allows the current process to continue execution without waiting.
I would consider sending email as a long running process, because you never know how long this might take, and for many situations (i.e. sending a welcome email) there isn’t much I would want to do if the mail didn’t send. I might implement retry logic, but that could go in the spawned process as well. If it ultimately does fail, I probably don’t want to show a cryptic and somewhat distressing “Failed to send welcome email” message to my user, so there is no point in making them wait. If you can show a useful error message, and determine it’s worth the tradeoff of making users wait longer in exchange for being able to show that message when there is a failure, then you can make it synchronous.
I use a mailing library called Bamboo that encourages asynchronous behavior with its deliver_later function, but it looks like with Swoosh you just need to spawn a process yourself if you want that. Conversely, for synchronous behavior Bamboo provides deliver_now, while that’s the default with Swoosh. I’ve mostly gone the asynchronous route, but hopefully this gives you some information on how/when to implement synchronous/asynchronous behavior.
2
dimitarvp
Yep, both Bamboo and Swoosh are alright.
One more step forward would be to enqueue mail-sending jobs to Oban and do synchronous sending in the working process you’re given when the job’s time to execute has come.
2
josefrichter
Is spawning a process like this outside of supervision tree ok in this case? I know in the past I actually spawned some Tasks under Task.Supervisor to send out emails. But that was my early days, not sure if that’s not overkill..
0
derek-zhou
For small to medium setup, the only 2 sane email sending methods are:
- use a reputable 3rd party services, such as Sendgrid or mailgun
- install a SMTP server very close, like in the same data center or even on the same machine
In either case, there are buffering on the other side already and the sending should be instantaneous. I see no point of spawning. In any event, retrying at the application server side will not help.
0
softrage
I agree that these are sane methods. Here’s an unscientific experiment sending bad requests from an instance on GCP to Sendgrid/Mailgun to see response times:
curl -d '{"bad":"data"}' -H "Content-Type: application/json" -X POST https://api.sendgrid.com/v3/marketing/test/send_email -s -o /dev/null -w "%{time_total}\n"
0.169216
curl -d '{"bad":"data"}' -H "Content-Type: application/json" -X POST https://api.mailgun.net/v3/mydomain.com -s -o /dev/null -w "%{time_total}\n"
0.272170
170ms/270ms extra in the normal case, with no HTML email body, is not quite free. When latency increases, or in the worse cases when a request fails for some reason (which they will on rare occasions, the case where retrying server side does help), or when the service has an outage (looking at you AWS!), then presumably the user is waiting much longer until Hackney times out to get a response. Since there’s no additional effort at least in the basic case, if I’m not planning to give an error to my user, I don’t see a reason not to spawn. It doesn’t make it more robust (unlike what @dimitarvp mentions), but if the email is going to successfully send or occasionally die either way, it might as well do it where my user doesn’t have to see 
2