If I call
Code: Select all
$ a | b
I use a very unclean implementation of that, but it works for simple examples, like
Code: Select all
$ hw | hexdump
00000000: 48 65 6C 6C 6F 2C 20 77 6F 72 6C 64 20 21 0A
Code: Select all
$ hexdump hw | more
Here are some excerpts from my syscalls. I know that they flood the stack, but I don't know how to fix that ...
Excerpt from syscall #0 ( putc )
Code: Select all
/* ... */
/* there is a master process so pass the character x to it */
currentProcess->master->tss.eax = x; // return value;
currentProcess->master->go();
/* ... */
Code: Select all
/* ... */
/* there is a slave process so activate it and wait for the character */
return currentProcess->slave->go();
/* ... */
So what happens is that:
I call "a | b" . <b> is activated and calls syscall 1 ( readkey ). My kernel activates process <a>. Process <a> calls syscall 0 ( putc ) . <a> is only active when the master has called readkey so it passes the character as return code to the master and re-activate the master.
Now to the problem, which is mainly caused by CProcess::go(). Everytime the kernel does a task switch, CProcess::go() is used.
Code: Select all
unsigned int CProcess::go() {
currentProcess = this;
tss.stack[0].esp = getESP()-12; // tss means this->tss. It's a local member of CProcess
return farJmp(tr,0); // tr is a local member, too
}
Maybe you already see the problem, but I give an example:
So lets use " a | b ". b has called readkey, and a has called putc, so the (kernel) stack could look like:
Code: Select all
syscall1 (readkey) // called by b
processA->go // called by kernel
farJmp // called by kernel
syscall0 ( putc ) // called by a
processB->go // called by kernel
farJmp // called by kernel