On 04.02.2014 22:52, Sébastien Villemot wrote: > Le mardi 04 février 2014 à 22:42 +0100, Julian Taylor a écrit : > >> it will deadlock eating all cpu in gomp at the end. >> This is the typical failure pattern caused by forks combined with gnu >> openmp (see https://github.com/xianyi/OpenBLAS/issues/294) >> >> But the weird part is this testsuite does not fork at all, so it might >> be a different issue. >> It did not occur when openblas was still using pthreads. > > These two paragraphs contradict each other. Is it a fork issue or not?
as I said it looks like a classical well known fork issue, but its not forking, so I don't know yet whats going on. > >> Given the problems openmp based openblas causes in the python world (see >> the linked issue) I would prefer if the change was reverted or openmp >> variant split into a separate alternative. > > I would rather keep the libopenblas-base package with OpenMP, and create > a new libopenblas-pthread0 package. > I would prefer it the other way round as in my experience pthread works better. But this viewpoint is of course scewed by the software I'm using. A compromise could be to have -base single threaded and provided two threaded alternatives documenting their issues. -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
