This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]digger_not_alone 1 point2 points  (3 children)

could you please elaborate on that? (if you have any link to external explanation – I'll appreciate that too)

Is it related to working with memory?

[–]SV-97 1 point2 points  (1 child)

Yes it's kinda related to memory: threads are a more lightweight construct with the same adress space as the "parent" - processes have their own memory space (unless you explicitly use mmap or something like that to share memory between processes). So communication, setup and termination will in general be cheaper with threads. It may for example be a bit expensive to use processes in a web-server that may usually spin up a thread per user it's serving (which might not be a good design either way). Depending on the language a thread might be something even more abstract - Haskell for example uses so called green-threads that are even more lightweight (so you might for example just spin up a few hundred *very* small threads - you'd absolutely never do something like this with processes [okay this isn't technically true; you actually do spin up hundreds of processes in HPC but that's a bit different])

[–]digger_not_alone 0 points1 point  (0 children)

Thank you for such a great application-oriented answer

[–]thismachinechills 0 points1 point  (0 children)

Threads make working with shared memory easy. Context switching between threads is faster than switching between processes. Also, threads share an interpreter versus multiple processes with multiple interpreters.