
== Bind workers to CPU ==

If environment variable MYTH_BIND_WORKERS is set to 0, MassiveThreads
does NOT bind workers to CPUs.

Otherwise it binds workers to CPUs, in which case workers are bound to
CPUs accroding to the following rules.

It first obtains the set of eligible CPUs via sched_getaffinity.  Let
S be the set sched_getaffinity returns.  This is the set of CPUs any
worker in this process can be bound to.

If environment variable MYTH_CPU_LIST is not set, CPUs in S are used
in the ascending order, to bind workers in the ascending order.  Excess
workers are cyclically assigned.  For
example, if S = { 2, 3, 5, 7, 11 }, 
worker 0 -> cpu 2,
worker 1 -> cpu 3,
worker 2 -> cpu 5,
worker 3 -> cpu 7,
worker 4 -> cpu 11,
worker 6 -> cpu 2,
worker 7 -> cpu 3,
   ...

Environment variable MYTH_CPU_LIST, if set, has an effect on the order
in which CPUs are used.  First, the any CPU not in S is removed from
the list.  The resulting CPU numbers are used in the order they appear
in the list.  For example, if MYTH_CPU_LIST=3,7,11,15, and S = { 2, 3,
5, 7, 11 }, CPUs 3, 7, and 11 are used (15 is removed because it is
not in S).  So, 

worker 0 is bound to CPU 3,
worker 1 is bound to CPU 7,
worker 2 is bound to CPU 11,
worker 3 is bound to CPU 3,
worker 4 is bound to CPU 7,
worker 5 is bound to CPU 11,
  ...

The syntax of MYTH_CPU_LIST allows a range as well as a strided range.

The full syntax is as follows.

cpu_list ::= range[,range]*
range    ::= num[-num[:num]]

range A-B is a shorthand of A,A+1,...,B-1.
range A-B:C is a short hand of A,A+C,A+2C,...,A+kC
where k is the larget number s.t. A+kC < B.


