mmarco wrote:
I am working on a patch to implement Zariski-Van Kampen method, and it
makes use of parallelization. For some reason, the use of plain
@parallel decorator (which uses fork) gives some problems, but it
works of if i use the multiprocessing option.
Solve the problem with @parallel in the first place? ;-)
But IIRC, multiprocessing library requires open semaphores support in
the kernel. I really don't know if it is enabled by default in most
distros or not, but anyways i would like to ask if it is ok to include
some function that requires a specific kernel configuration (and that
hence, could not work on some systems).
try:
from multiprocessing.synchronize import ...
...
# probably need to catch further exceptions upon construction
...
except ImportError:
# use a single-threaded fall-back implementation or give
# an appropriate error message
AFAIK, /building/ the Sage library also requires semaphores to work
(even if SAGE_NUM_THREADS=1, which is odd, and we still don't even check
this in advance), so at least /trying/ to use it should be ok... :-)
So, is it ok? And if it is not, is there a way to circumvent this
issue? (besides disabling parallelism, which is not really a good idea
since the method can take a long time, and is trivially
parallelizable).
In any case, the maximum number of threads used should IMHO by default
be limited to SAGE_NUM_THREADS.
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
