# HG changeset patch # User Olivier Delalleau # Date 1285258719 14400 # Node ID 808e38dce8d6052af21b52a6f1d67a3014140e4d # Parent 6d97f32c3fdfc243c913d927a6f8b3b1f3596709 Replied to YB's comment on JB's system diff -r 6d97f32c3fdf -r 808e38dce8d6 doc/v2_planning/arch_src/plugin_JB_comments_YB.txt --- a/doc/v2_planning/arch_src/plugin_JB_comments_YB.txt Thu Sep 23 12:11:44 2010 -0400 +++ b/doc/v2_planning/arch_src/plugin_JB_comments_YB.txt Thu Sep 23 12:18:39 2010 -0400 @@ -45,3 +45,13 @@ I think the advantage of making the program aware where in its own execution flow it is and what is its execution flow can be quite useful for automating some of the things we want. + +OD comments: I agree with Yoshua. I actually thought (by watching at the +discussions in these files from a rather high-level point-of-view) the main +goal of this machinery was to help with parallelization. If that is the case, +it may prove useful in some places, but it is not something that one would +want to use everywhere. As far as serialization is concerned, I think this +should be do-able without such a system (provided we all agree that we do not +necessarily require the ability to serialize / restart at any point). About +the ability to move / substitute things, you could probably achieve the same +goal with proper code factorization / conventions.