On 23/10/12 23:03 , Michael Bishop wrote:
Hi Everyone,
*A Perk of the ThreadPool Implementation*
The reason I ask if the issue isn't simply about "what -j means" is
because the drake implementation is documented as breaking the existing
contract exposed by the Rake API. From the drake page (
http://quix.github.com/rake/files/doc/parallel_rdoc.html ):
Task#invoke inside Task#invoke
Parallelizing tasks means surrendering control over the
micro-management
of their execution. Manually invoking tasks inside other tasks is
rather
contrary to this notion, throwing a monkey wrench into the system. An
exception will be raised when this is attempted in -j mode.
The ThreadPool implementation does not share this same limitation or
limit any features of the Rake API.
[A use case for this is below...]
I have a much better use case and since my patch for allowing this
within the tasks was rejected because of abuse potential I'm dreading
losing the ability to use invoke within tasks.
What I do is
task build
t=calculate_task_with_dynamic_dependencies(params)
Task[t].invoke
end
Now for various reasons import and other tricks do not work for my use
case (there's a bit more info on the pull request for dynamic prereqs
https://github.com/jimweirich/rake/pull/103) but the above idiom works
really well.
Not allowing it would be fatal for my system.
I'll also +1 the differentiation of -m and -j.
Much prefer explicitly specifying MultiTask instead of having to hunt
down subtle race condition and resource contention bugs because of the
implicitly multi threaded environment.
Cheers,
V.-
--
http://www.ampelofilosofies.gr
_______________________________________________
Rake-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rake-devel
