2 ms·
In this example, I could see a library parsing xml spin off a process so it can track state. I could also see a performance argument for not wanting to do pote
by freedomben 3y ago
In this example, I could see a library parsing xml spin off a process so it can track state. I could also see a performance argument for not wanting to do potentially computationally expensives (or even I/O expensive) work on the main process blocking other things.
I'm not enough of a parser expert to know whether stateless processing is possible, but that's how I can see a simple xml parser ending up in a separate process.
- throwawaymaths 3y ago"parsing xml spin off a process so it can track state" Don't do that. Use state tracking data type. "the main process" That's not a thing in the BEAM. For something pure compute (i.e. no need for connection pools), if your user really needs that, then they can run the xml parsing in their own spawned process. Even if it's I/O bound, Erlang VM already makes great decisions about yielding, you will almost certainly not do better. You should not make concurrency decision on the users behalf.