1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
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.
|
