Truth, Computing and Fail

This might seem trivial at first sight but you have no idea how darn happy I’m to see this works . So happy that I decided to blog about it. I already hear trumpets blowing in the distance.

Here is what I was worried about:

Normally, exec() is carried out in a forked process. Setting resource limits on a forked process is straightforward using setrlimit(). But I was apprehensive whether those limits would hold once I exec() another binary image within that forked process, and it wouldn’t be overstating it if I said I was about to front kick my laptop in joy .

I tested by limiting the amount of CPU time(RLIMIT_CPU) that a running process is allocated since this would be the easiest to test IMO. The signal delivered to the process when it exceeds the CPU time limit is SIGXCPU.

Since this is all that is to it, wasting no more words, let’s get our hands dirty.

The program in which a process is forked and exec() is run (exec.c):

#include <stdio.h>
#include <stdlib.h>
#include <sys/resource.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>

int main()
{
    int pid;
    int rv;

    if (!( pid=fork() ))
    {
        struct rlimit limit;
        getrlimit(RLIMIT_CPU, &limit);

        limit.rlim_cur = 1;

        setrlimit(RLIMIT_CPU, &limit);

        execl("./inf","inf",NULL);
    }
    else if(pid)
    {
        wait(&rv);
    }
    else
        printf("Error forking\n");

    return 0;
}

The program whose binary image is specified in exec() (inf.c):

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

void handler(int signum)
{
    if (signum == SIGXCPU)
        printf("Caught SIGXCPU signal, exec in peace\n");
}

int main()
{
signal(SIGXCPU, handler);
while(1);
return 0;
}

Now compile
$gcc -Wall exec.c -o exec
$gcc -Wall inf.c -o inf

and run
$./exec

You’ll see SIGXCPU being handled which means the resource limit is working!

No big deal. Everyone has to do it once for their UNIX concepts practical work I guess. What irked me was that the teacher and some of the ‘good students’ were hell bent on arguing that non-preemptive process scheduling simulations do not require any kind of data regarding the arrival time of processes in the ready queue. I still don’t understand how that simulates a real life scenario, that is, after the completion of a process, to which other process would the scheduler perform a context switch. Could someone point me out if I am missing something here?

Anyways, this is the code I wrote today during the practical class:

#include<stdio.h>

struct processinfo

{

        int id;

        int burst;

        int arr;

};

typedef struct processinfo process;

/*checks if all the processes have finished execution*/

int check(process* p,int n)

{

        int i=0,flag=0;

        for(i=0;i<n;i++)

        {

                if(p[i].burst!=0)

                {

                        flag=1;

                        break;

                }

        }

        return flag;

}

int main()

{

        int n;

        printf("No. of processes:");

        scanf("%d",&n);

        process p[n];

        int i=0,j=0;

        int wt[n]/*the waiting time array*/,last[n]/*last[i] stores the last executed instant of the process i*/;

        for(i=0;i<n;i++)

        {

        	printf("Proccess id:");

        	scanf("%d",&p[i].id);

                printf("Arrival time:");

                scanf("%d",&p[i].arr);

                printf("Burst time:");

                scanf("%d",&p[i].burst);

                wt[i]=0;

                last[i]=0;

        }

        /*gah, bubble sort*/

       /*anyways we won't be doing any sorting in a real scheduler, I guess*/

        for(i=0;i<n-1;i++)
		{

        	for(j=i+1;j<n;j++)

        	{

                if(p[j-1].arr>p[j].arr)

                {

                 process temp=p[j-1];

                 p[j-1]=p[j];

                 p[j]=temp;

                }

        	}

		}

int timequantum=2/*the time quantum*/,time=0/*running time*/;

while(1)

{

        if(!check(p,n))

                break;

	int k=0;

for(k=0;k<n;k++)

{

        if(p[k].burst!=0)

        {

                if(p[k].burst<timequantum)

                {

                        wt[k]+=time-last[k];

                        time+=p[k].burst;

                        p[k].burst=0;

                }

                else

                {

                        p[k].burst-=timequantum;

                        wt[k]+=time-last[k];

                        time+=timequantum;

                }
                last[k]=time;
        }

}

 }//end of while

for(i=0;i<n;i++)

	printf("\nWaiting time for Process %d:%d",p[i].id,wt[i]);

return 0;

}

This is meant for NASM running on a linux machine. First things first: everything in UNIX is a file. A device is a file, a network socket is a file and everything else you can imagine is a file. Each file has a file descriptor attached to it. Some standard file descriptors are 0 for STDIN (standard input), 1 for STDOUT (standard output) and 2 for STDERR (standard error output). Since everything is a file, you can read() and write() on them provided you have the file descriptor.

read(), write() and open() are some of the very important syscalls in linux that would allow you to manipulate any file (that is, provided you have the permissions). There are some 150+ of them if you are really interested to find out. For syscalls, you need to pass the necessary parameters in the ebx, ecx, edx registers and so on, depending upon the number of parameters. You can also call libc functions by declaring them as extern printf for example and pushing the necessary parameters on the stack, the last parameter to be pushed first. To understand what kind of parameters need to be passed for the syscalls, read the developer man pages. Like man 2 write for write(). Use this for any other syscall like read() or open() and also keep the list of syscalls mentioned earlier in this post handy.

Regarding passing arguments to the program, they are stored in the stack as

argc
argv[0]
argv[1]
argv[2]

and so on…
argv[0] is the program name itself, so we can pop and discard it safely.

The following is a small program in NASM that takes a filename as an argument and reads 8kB from the file and displays it on the screen.

section .data
buf times 8 db 0
bufsize db 8192

section .text
global _start

_start:
pop ebx
pop ebx
pop ebx
mov eax,5
mov ecx,2	;the read mode
int 80h

test eax,eax
jns file_read

mov ebx,eax
mov eax,1
int 80h
ret

file_read:
mov ebx,eax	;move the file descriptor
mov eax,3	;3 for read()
mov ecx,buf	;the buffer
mov edx,bufsize	;the buffer size
int 80h

mov edx,eax	;move the number of bytes read from the previous syscall to edx
mov eax,4	;4 for write()
mov ebx,1	;1, the STDOUT file descriptor
int 80h

mov eax,1
mov ebx,0
int 80h		;exit with error code 0
ret

To assemble: nasm -f elf filename.asm
To link: ld -s -o executable-name filename.o

To know more about the read and write modes, the file descriptors and some increased masochistic behavior, start with reading the /usr/include/unistd.h and /usr/include/fcntl.h files. Poke around that directory for some more knowledge.