As I make my journey through the wonderful world of Erlang I notice its beauty, but more importantly I notice its speed. Which makes me wonder, since Erlang is so good at spawning lightweight processes, does it make sense to use it as a wrapper around other processes.
As an example, I use rspec to write tests for ruby. Say I have 10,000 tests that all can be run independently with no problems. Would it make sense to use Erlang spawn 10,000 rspecs and run each test concurrently as opposed to rspec running each one seque开发者_开发知识库ntially? Or is this just a completely ridiculous idea?
You are confusing erlang processes with OS processes. The erlang VM runs in an OS process, interpreting and running erlang programs (compiled in beam files). When an erlang program calls spawn
or spawn_link
the VM creates an internal process that will be run by the internal VM scheduler. The OS knows nothing about those processes.
However, when an erlang program spawns a port (the usual way of running external programs like the ruby interpreter in your case), it creates a new OS process external to the VM. That external process communicates with the VM using the standard input output. If you see the processes in your system, you will notice that there is one beam process (the erlang VM) and one ruby process.
So launching OS processes from the erlang VM will not make any difference compared to launching them by any other means (by hand, in a shell script, etc)
I'm guessing that rspecs are heavyweight processes, in which case 10,000 of them will bring any OS to its knees, even if they are "wrapped" in Erlang processes. Erlang's processes aren't genuine processes in the OS sense, and they can't imbue normal OS processes with their "magical" properties. They just ask the OS to spawn the process.
精彩评论