[Rake-devel] recursive task invocation

Ittay Dror ittay.dror at gmail.com
Mon Aug 11 09:35:34 EDT 2008

Ittay Dror wrote:
> Hi,
> I'm running a Buildr build and after 20 recursive prerequisites Ruby's 
> call stack is exhausted and I get a segmentation fault. The number of 
> modules and dependencies is large, so I can't decrease the prerequisites.
> How about doing an iterative DFS search on the prerequisites to order 
> them and then invoke them according to order?
> There are  a few other benefits, besides not needing recursion:
> 1. it allows to find circular dependencies before starting the invocation
> 2. it allows for rake to utilize threads to invoke the list of tasks 
> (assuming actions don't conflict)
Note that the current use of threads, in either MultiTask, or the 
JobTask I sent earlier is faulty. Imagine tasks A, B, C, D where  A => 
[B, C], B=>[D], C=>[D]. Now if B and C are invoked in parallel, C 
invokes D which fails. C promptly fails. B continues to run and to it D 
seems to have been already invoked, so it does its actions assuming D's 
actions were executed which isn't true. Now even if the 
MultiTask/JobTask were to cause all other threads to fail, there can be 
nested MultiTask/JobTask already running and the whole issue becomes messy.
> Note that currently tasks can "cheat" and add prerequisites lazily 
> when invoked by overriding invoke_prerequisites. This can be achieved 
> with the above suggestion by letting them override the prerequisites 
> accessor.
> Drawbacks:
> This doesn't allow for a task's action to add prerequisites to sibling 
> tasks during the invocation chain (unless an API is provided to allow 
> changing the invocation list during invocation)
> What do you think? I don't mind implementing this, but obviously it is 
> a big change.
> Ittay

Ittay Dror <ittay.dror at gmail.com>

More information about the Rake-devel mailing list