I'm trying to optimize an elliptic curve factoring method by running it in parallel. There is a recursive step which required me to set the recursion limit higher than 256, however when I try and run it in parallel apparently the $RecursionLimit on each different kernel isn't changed.

Here's part of the output:

In[76]:= ParallelECFactor[2418059292539721278076064468260051655561,1000,40]
(kernel 4) $RecursionLimit::reclim: Recursion depth of 256 exceeded.
(kernel 3) $RecursionLimit::reclim: Recursion depth of 256 exceeded.
(kernel 2) $RecursionLimit::reclim: Recursion depth of 256 exceeded.
(kernel 1) $RecursionLimit::reclim: Recursion depth of 256 exceeded.
(* and many more *)

1 Answer 1


As sebhofer pointed out, my previous solution didn't work — a fact that I missed because I wrote it without an mma to test. The users who voted for it also must've missed it, because on the surface it looks like a straightshot answer, but no. So, here's Jackson's solution that works — Use ParallelEvaluate as:

ParallelEvaluate[$RecursionLimit = 10^6]

Here's my previous solution that doesn't work, but I'm leaving it here so that others will not try something similar.

Block[{$RecursionLimit = Infinity},
    (* your parallel code *)

Using Block allows you to temporarily modify $RecursionLimit so that the global value is unaffected andSetSharedVariable declares that the variable's value is synchronized across all kernels.

  • 2
    $\begingroup$ Yea I think that would work. As soon as you posted that I realized I could just do this: ParallelEvaluate[$RecursionLimit = 10^6] $\endgroup$ Apr 1, 2012 at 23:44
  • $\begingroup$ R.M: Your code does not work for me (version 8.0.4)! ParallelEvaluate[$RecursionLimit = 10^6] does work though. $\endgroup$
    – sebhofer
    Apr 2, 2012 at 19:12
  • $\begingroup$ @sebhofer Oh dear. Thanks for pointing that. I wrote it without mma at hand, and did not catch the error. Apparently, the parallel kernels don't see the modified value. I'll try to fix it later or if not, I'll delete it. $\endgroup$
    – rm -rf
    Apr 2, 2012 at 19:25
  • $\begingroup$ I think it's worth noting that, at least on Windows or Mac, setting $RecursionLimit as high as $10^6$ is liable to crash the kernel(s) due to stack overflow. On Linux it should be okay since there the stack can grow as large as necessary. $\endgroup$ Apr 3, 2012 at 12:47
  • $\begingroup$ Yes, it's because setting a shared variable isn't the same as doing DistributeDefinitions. Shared variables are read from the master kernel whenever they're referenced in the subkernels using a callback. $RecursionLimit is treated specially by the kernel; its value can only be either an integer 20 or greater, or Infinity. This excludes setting its value to the expression that performs the callback. Using DistributeDefinitions would have worked, however. $\endgroup$ Apr 3, 2012 at 14:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.