From 31fa2d4836ce93993aa94364b1c3dd2195c90142 Mon Sep 17 00:00:00 2001 From: Mike Buland Date: Wed, 21 Sep 2016 12:04:25 -0600 Subject: Saved the threading plan from the branch. This was the only useful thing in the threading breanch. --- docs/threading-plan.txt | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 docs/threading-plan.txt diff --git a/docs/threading-plan.txt b/docs/threading-plan.txt new file mode 100644 index 0000000..794d60f --- /dev/null +++ b/docs/threading-plan.txt @@ -0,0 +1,28 @@ +It looks like the following changes will have to happen in order to allow build +to bu truly multi-threaded. We can't proceed like I originally thought, the +entire system is build-script driven, including the profiles that do the actual +building. + +1. Context needs to be broken apart into everything it currently has except + the ScopeStack, and the ScopeStack. The initial ScopeStack (the root level) + will be built before the program goes multi-thraeded, then it will be copied + into each thread so they all start with the same global state. + Targets will still be built the same way, so we won't have to worry about + targets' global variable overrides. +2. Instead of each target actually processing it's complete list of dependancies + when it's processed, it should create a queue of them. This may well be the + biggest change, but it still should be fairly doable. We'll still process + them in the same order, which will make things pretty easy. + That queue will be global, and will be what feeds the thread dispatcher. +3. A new thread handler and thread class needs to be created. The threads will + dequeue targets from the target queue and process them provided all + prerequisites have been completed. We can do this a few ways, but I think + a simple loop will suffice. + Loop steps: + 1. Check all deps on target, if completed, then execute, otherwise: + 2. Wait on condition that is triggered every time a target is completed. + 3. Go back to 1 +4. View needs to be made completely thread-safe, I'm thinking maybe through a + View system middle layer handler in order to keep the specific View code + pretty simple. + -- cgit v1.2.3