Clarification on Sending Emails Asynchronously

I think it refers to the fact that every single connection is handled by a separate independent process, so a slow operation, or even a crash, does not slow down or directly affect any other connection. I think this is a good explanation what’s going on under the hood: https://elixir-lang.org/getting-started/mix-otp/task-and-gen-tcp.html

But I’d too like to see a confirmation or more profound answer from some of the OGs here

Two things that this might be referring to (but they’re both a stretch):

• in the early days of Node, libraries would hide blocking calls (like an SMTP send) and cause scheduling woes by blocking the whole event loop. But nowadays there are well-established patterns for handling that situation (async/await etc)

• a web server running on the BEAM is going to have a LOT more “workers” than one with traditional UNIX processes, so blocking one Erlang process should have less effect on performance

I think that’s the point - in Node or Ruby you have to use these workarounds to make sure you don’t choke the system, and still have fairly limited options. In Elixir you don’t. Because of your bullet 2, basically.

If I overly simplify it, Ruby and Node are running in single thread by default. Elixir runs on all available threads by default. On my macbook, this means 6 cores = 12 threads, so I kinda get 12x performance out of the box. It’s easy to choke 1 thread, especially if something goes awry and gets stuck there. Async/await helps you optimize within that one thread, but nothing more. You don’t need that much optimization if you run on 12x more threads. So you would most likely send mails asynchronously in Elixir for example when it’s imperative that within your application the single user cannot wait 0.5s for the mailer response. At least that is my layman understanding here, hopefully someone more experienced can chime in?

I can’t find the thread but I remember folks arguing that, since the majority of people will be using a third party to actually send the email, and those third party usually send emails in a reasonable time, it was OK to simply call the API to fire the message and be done with it.

It goes even further than that. Elixir’s processes are not only OS threads; you can still have tens of thousands of processes and parts of them might be stuck (and that count can be much more than the amount of CPU cores) but the rest will still continue running.

Exactly, Erlang runs the processes in schedulers. By default there is one scheduler per CPU core, so on a 12-core system you would have 12 schedulers. The processes are switched pre-emptively, meaning that a process cannot prevent the scheduler from running other processes (except in the case of NIFs but that’s a separate problem). So even if you have one process stuck or spinning infinitely, it will be periodically switched out and the scheduler will run something else.

This is the real reason why you can technically run long running blocking tasks in the same process as the HTTP request. Assuming you have already sent the response to the user, then there is no problem if the process takes a long time to send the email or do something else, it won’t block anything else important running on the system.

Thank you for this. To further understand, when you say “process stuck or spinning indefinitely”, would that mean the process is stuck “in” CPU? Blocking one thread?

And if one core = two threads, then each scheduler has 2 threads to work with, and can use the other one if one of them is blocked?

Also, what decides which of the scheduler takes any given process?

By “stuck” I meant a process that is blocked, passively waiting for something. That process will not be scheduled for execution, the scheduler will run other processes. By “spinning indefinitely” I mean a process that is in an infinite loop, constantly executing. It will be executed by the scheduler but periodically switched out, so other processes will also get execution time.

Schedulers are single threads in the OS PoV, so for one core you would generally have one scheduler. It doesn’t make sense to say “if one of [the threads] is blocked” as the scheduler is single threaded and won’t get blocked by regular Erlang processes.

The VM orchestrates the schedulers. They can steal work from each other, so if one is overloaded, others can take processes from it to manage the load.

thank you again. what resource would you recommend for reading up more on this, please?

https://www.youtube.com/watch?v=JvBT4XBdoUE is a classic talk that covers these cool properties.