Consider changing PyTables default number of threads

[EricR86]

Original report (archived issue) by Coby Viner (Bitbucket: cviner2, GitHub: cviner).

---

PyTables defaults to using 4 threads. This could pose a problem for cluster usage and could also be made more efficient when more slots are available.

It may be worthwhile for Genomedata to override the default values of tables.parameters.MAX_NUMEXPR_THREADS and tables.parameters.MAX_BLOSC_THREADS.

If not, this behaviour is likely something that Genomedata should explicitly document.

[EricR86]

Original comment by Michael Hoffman (Bitbucket: hoffman, GitHub: michaelmhoffman).

---

@EricR86 Can you please document this in Genomedata? I don't think there needs to be an option to set this within Genomedata. Client programs can change directly using the tables interface if they need to.

segway-task should also set both of these to one since there is an assumption that one Segway task = one thread. I don't think any other part of Segway or Segtools should be modified, for now. Then you can close this.

[EricR86]

Original comment by Eric Roberts (Bitbucket: ericr86, GitHub: ericr86).

---

@michaelmhoffman If there doesn't need to be an option set to this within Genomedata, why document this particular PyTables interface feature? There are plenty of other PyTables parameters that could be documented as well.

[EricR86]

Original comment by Michael Hoffman (Bitbucket: hoffman, GitHub: michaelmhoffman).

---

Many people will be in an environment where they assume one thread per process unless they do something to change it. And they might violate, say, a cluster use policy to declare the number of threads or cores being used, if they aren't made aware of this.

[EricR86]

Original comment by Coby Viner (Bitbucket: cviner2, GitHub: cviner).

---

• changed state from "new" to "open"