Scheduling policies

0. Big picture:
1. Creating new PIDs will always block the original thread
2. Use fork() to create new thread 1. Thus spawning new process <=> fork() then exec()/makeKThread()
3. different from Linux because of course requirements.
4. exec() actually creates a new Process
5. and it's the only function to create a new user process
6. fork() creates a new Thread
7. this is the only way to create a new task without blocking the original one
8. Thus, this is very useful for instantiating multiple terminals
9. makeKThread() creates a new Kernel "Process" (A new process with a single kernel thread).
10. should be renamed to execKernel() (it also blocks the parent thread)
11. which can call exec() to create a whole new user process.
12. makeKThread accepts argument to customize everything about this "Kernel Process" 1. Although "Kernel Process" does not have its own memmap, 2. Kernel Process's execChild process inherit its Terminal/GUI client handle. 3. Thus we utilize makeKThread when creating new Terminals/GUIs
13. We use makeKThread to instantiate the 4 different shells on the 4 Text-mode Terminals.
14. Because: if we use fork() to accomplish this, fork() must be able to move some program from terminal 0 to terminal 3, which is unsafe and breaks abstraction.

about tasklets

Just use makeKThread() in the interrupt handler.

about terminal read & blocking:

If we allow "blocking inside syscall":

Easy. block the syscall and wake it when interrupt arrives.

If we disallow "blocking inside syscall":

We have to split all "blocking" into two pieces:

either interrupt handler & tasklet, or before-blocking and after-blocking.

About signals:

There is a way to get signal and blocking working together. (draft)

1. terminal is owned by single thread, not a whole process
2. signal is sent between threads, not between whole processes
3. there is a record about which thread is the "ui thread" so no worry.
4. Two ways to implement "keyboard blocking":
5. Keep the current approach and disable signals
6. Use signals to implement all "blocking". Never provide other approaches: 0. BAD design: read() may fail due to other signals' interruption... 1. Define a SIG_BLKOVER signal.
   1. Currently we do not care about what the handler does.
   2. Its only function is to bring the task back into scheduler. 2. Then drivers can implement blocking in many ways. Here is a SIMPLE way (NOT best way):
   3. Upon syscall request: block the user thread by removing it from scheduler queues. Then the scheduler will find another active task to switch to.
   4. Don't worry about context though, when the syscall happened, everything has been saved to PCB.
   5. Driver should store the syscall arguments (such as buffer, nbytes) in PCB or File Descriptor.
   6. Upon interrupt (completion of blocking): Read syscall arguments stored in File Descriptor or PCB, and Modify the user thread's PCB->getRegs() to complete the syscall. In the end, it sends a SYS_BLKOVER signal to that thread to wake it up.