-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathdesign_doc.txt
More file actions
129 lines (99 loc) · 3.83 KB
/
design_doc.txt
File metadata and controls
129 lines (99 loc) · 3.83 KB
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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
################
Paul Benoit
################
Name1: Paul Benoit
EID1: pjb742
CS login: paulbeno
Email: paul.benoit36@gmail.com
Unique Number: 53015
Slip days used: 0
****EACH student submits a (unique) design document.****
################
Zoe Lamb
################
Name1: Zoe Lamb
EID1: zl2866
CS login: zoe
Email: zlamb@utexas.edu
Unique Number: 53005
Your partner's ranking (scale below): Excellent
################
PARTNER EVALUATION SCALE
################
Excellent: Consistently went above and beyond - tutored others, carried
more than his/her fair share of the load.
Very Good: Consistently did what he/she was supposed to do, very well
prepared and cooperative.
Satisfactory: Usually did what he/she was supposed to do, minimally
prepared and cooperative.
Marginal: Sometimes failed to show up and/or rarely prepared.
Deficient: Often failed to show up and/or rarely prepared.
Unsatisfactory: Consistently failed to show up and/or unprepared.
Superficial: Practically no participation.
No Show: No participation at all.
################
Preliminaries
################
(1) If you have any preliminary comments on your submission, notes for
the TAs, or extra credit, please give them here.
(2) Please cite any offline or online sources you consulted while
preparing your submission, other than the Linux documentation,
course text, and lecture notes.
Computer Systems A Programmer's Perspective by Bryant and O'Hallaron
################
Questions regarding Part 0
################
(1) How many child processes are created when doFib() begins with
an input of 5? Show the return value for each child process, numbering
the processes beginning with 0 (the original process) and incrementing for
each child process.
14 child processes.
Process 0 returns 5
Process 1a returns 3
Process 1b returns 2
Process 2a returns 1
Process 2b returns 1
Process 2c returns 1
Process 2d returns 2
PRocess 3a returns 0;
Process 3b returns 1;
Process 3c returns 0;
Process 3d returns 1;
Process 3e returns 1;
Process 3f returns 1;
Process 4a returns 0;
Process 4b returns 1;
Other process 2 retuns 1 from process
(2) In part 0.3, which flavor of exec did you choose to use? Why?
We used execv since we did not need to utilize the environment variable.
################
Questions regarding Part 1
################
(1) In the provided utility function Signal(), what does the call to
sigaction() do? Why was sigaction() used instead of signal()?
sigaction allows users to clearly specify the signal handling
semantics they want, and the user has to set the entries of a
structure.
(2) What is the last assembly language instruction executed by the
signal handler function that you write? (You may choose either signal
handler.)
The last instruction was retq.
(3) After the instruction identified in the previous question executes,
what is the next assembly language instruction executed?
The next instruction was in main(): mov %eax, -0x4(%rbp)
(4) When the signal handler finishes running, it must restore all of
the registers from the interrupted thread to exactly their values
before the signal occurred. How is this done?
The register values that are going to be restored are stored in the PCB,
so before the handler returns to main it has to restore the values
from the PCB, only after that does it return to user mode.
################
Questions regarding Part 2
################
(1) In msh.c, we use three separate signal handlers to catch our signals.
You can also use a single signal handler to catch all three signals. Is
there a design advantage of one over the other? Explain your answer.
If there is only one handler then any other signals that are sent to
that handler are blocked. On the other hand, if you have separate
handlers for each signal type, then pending signals of different types
are not blocked.