mschubert / clustermq

R package to send function calls as jobs on LSF, SGE, Slurm, PBS/Torque, or each via SSH
https://mschubert.github.io/clustermq/
Apache License 2.0
146 stars 27 forks source link

TERMINOLOGY: process instead of thread #118

Closed HenrikBengtsson closed 5 years ago

HenrikBengtsson commented 5 years ago

I noticed that you, in https://github.com/mschubert/clustermq/wiki/Configuration, wrote

Multicore will run the full network processing between local threads ...

Multicore (by the parallel package) uses 'forked processes' not 'threads'. AFAIU, it is important to distinguish threads from processes. Specifically, a thread (of a process) share the address space ("memory") with all the other threads in the same process. In constrast, processes (forked or separatly launched) does not share the same address space (although the OS is uses lazy copying when it comes to memory of forked processes).

There's also one occurance of 'threads' in https://github.com/mschubert/clustermq/blob/bc272599aaebe7c6f14bcec6755726bc425b0fdc/CHANGES.md

PS. In my work I sometimes use the term "worker" instead of "process" to avoid being to technical, e.g. "R background workers" (or just "R workers") instead of "R background processes".

mschubert commented 5 years ago

CHANGES.md refers to ZeroMQ IO threads, which is correct.

But forking results in new processes, not threads - you are right (although IIRC memory is shared copy-on-write for forking as well).

I went with "local R sessions" now.