vish is alive and kicking butt!

vish works great! Feels good. The data corruption had nothing to do with fork(). It was happening because I was trying to hold on to some data on the stack! I must be getting old. Need to work the pipe facility and possibly wildcards into this new shell.

Also, even though I am passing the environment string array into execve(), it does not seem to use it and is forcing me to supply full path names of commands I want to execute. Will figure out what is going on later. For now, this is a good point to break and move on to later topics in the book (process management etc.)

Writing a new shell

So I started writing my own shell called 'vish'. Lots of issues. The 'execve' system call does not seem to work consistently. I tried to track down the problem and what I found is this: I have a pointer to an array of strings which represent the command arguments that the user types in. I am using strtok to parse user input and build this structure. But as soon as I call fork(), this data structure is getting corrupted in both the parent and child processes. This just does not make any sense. Will get back and take a closer look.

Process Scheduling

Just went through various algorithms for process scheduling. The one that really interests me is Lottery Scheduling. Can't wait to get into how exactly scheduling is implemented in Minix.

On an unrelated note, I am about to start writing my own shell. Think I will call it vish! I guess this shell could produce error messages that start with "You vish".

Programming with semaphores

Just studied the different examples on using semaphores in the Tanenbaum book. Consider a non-trivial one like the solution given for the Dining Philosopher's problem. Sitting and staring at the algorithm for hours helps you understand it but not in such a way that you can recall it at a later time. Nor is it easy to find flaws in these algorithms just by inspection. I think that the only way to get good at using semaphores intelligently is to spend lots of time programming and debugging with them. If you don't use it you lose it.

Race conditions are painful because of their unpredictability.

Semaphores

But then, race conditions can happen in Petersen's approach too and even in the sleep/wake-up approach suggested in the producer-consumer (which share a read-write buffer) problem. That is where Djikstra's semaphores come in. Semaphores basically keep track of pending wake-up calls and account for each of them. Semaphore 'ups/downs' are analogous to 'wake-ups/sleeps' in the producer-consumer problem.

Cooperating processes

I am currently reading about different approaches to ensure protection of shared resources in a system that supports multiples processes: the concept of mutual exclusion. Petersen's approach is very simple and elegant. A variant of this relies on the hardware by using the TSL hardware instruction. Fun stuff.

I also wrote and tested a C program that tests most of the system calls on Ubuntu Linux 9.0.4. It was a great experience. The actual exercise is to test this on Minix but I don't yet have a machine on which I can install and play with Minix.