[erlang-questions] How many async threads can be spawned in dual core system ?

[Valentin Micic]

One time I've deployed a ridiculous systems using highly fragmented disk-only (dets) mnesia tables, and I started close to 1000 threads -- which roughly corresponded to a number of fragments in the schema.
The system worked.

CAVEAT EMPTOR: once I had a power failure and all those dets files required repair. I've restarted the system using the same number of threads, but it ran out of memory as each threads during the repair somehow utilized more memory. I've never quite understood why, but fixed it by reducing a number of thread during the repair, and then restarted the system with the same amount of threads without any further problems. 

V/

On 31 May 2017, at 10:21 AM, zxq9 wrote:

> On 2017年05月31日 水曜日 13:21:29 lankeanandrao wrote:
>>     I want to know, How many maximum number of async threads can be 
>> spawned for dual core processor.
> 
> As many as the other aspects of your system can handle.
> "Other aspects" meaning: memory, your Erlang runtime's settings, etc.
> 
> "Threads" are a poor way of thinking about this. Erlang processes are Erlang processes. Generally speaking, that is the level of abstraction you should be concerned with, not "threads" which is a different level of abstraction entirely (by every common definition of "thread").
> 
> The Erlang runtime will by default spawn a "scheduler" per thing that appears in your operating system as a "core" (an actual CPU core, or a "hyperthread", a virtualized core, or whatever). These schedulers are OS-level threads and work together to share the work of your Erlang processes among them. Within the Erlang runtime, though, you spawn as many processes as you want, and the schedulers take care of making sure they each get a "fair" amount of execution time among them.
> 
> I am generalizing a lot, but basically you don't think about things in terms of "how many cores do I have and how many threads does that let me use..." and so on. That is quite low-level. Erlang abstracts that away -- which is one of the powerful reasons for using it when you are trying to write a low-latency, highly concurrent system that experienced graceful performance degradation under load.
> 
> If you are unfamiliar with the "concurrency-oriented programming" paradigm present in Erlang (similr to "the actor model", though different for a number of nit-picky academic reasons) this may be helpful to skim through:
> https://stackoverflow.com/questions/32294367/erlang-process-vs-java-thread
> 
> -Craig
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions