hi,
has anyone gotten to the stage where their OS/KERNEL can attend to an active interractive task while others run in the background? I do not mean MULTITASKING/MULTITHREADING but by interractive i mean the task could be asking for input from keyboard/mouse etc while other task continue in the background.
I have done my keyboard driver and was testing my server idea for handling requests.
The servers keep lists of pending request for services and attend to them in a FIFO order.This is where i'm reflecting on the best cause of action.
If you are running an interractive task (i.e its the active one) it should be the only one that if it requests for input from the keyboard should get it but the other background tasks' requests should be ignored. How would you handle that?
example
the system has 3 ready tasks, A, B and C that only need the CPU to be able to execute.
the user instructs the monitor to set task A as the active(foreground task ie it the one they want to work with) while tasks B and C can be scheduled to run in the background. now the users is suppose to supply input to tasks A at random times and tasks B and C also have places where the users has to supply input but these tasks shouldn't get what the user types since task A is the designated active task.
I was thinking of handling this as follows:-
I have a Process Control Block that points to the task that is choosen as Active and another that Points to the current Running task selected by the scheduler.
Now its up to the server to decide how to handle its list of requests.
For my keyboard, i was thinking of getting the request at the head of the list, compare PID of the task that made the request with the PID of the ACTIVE task, if they match then the request is handled but if they do not then i move to the next request in the list and repeat the process.
I choose this scheme so that the FIFO order is maintained.
Any suggestions please?
thanks
I/O scheduling
-
Tim
Re:I/O scheduling
Mobius sidesteps the issue by having the console server take care of all keyboard input. When I get my GUI going, this will be up to the window manager.
The keyboard driver, and the kernel in general, have no concept of the 'active task'. The keyboard driver will give keypress information to any thread that asks for it. When the keyboard driver gets a DEV_READ request, it places it in a queue (=linked list); when it receives a keyboard interrupt, it places the key code in the buffer of all active requests and completes those that have enough keys.
Usually the console server will be the only process that reads from the keyboard (although this is not enforced; if another process reads from the keyboard it is possible that console.exe will miss keypresses). The console server is the one that knows what interactive processes are running, and which one is active. When a key is pressed, it just sends the ASCII code down the pipe for the active console. Each console isn't necessarily associated with one process; a console can have no process (the shell there has exited) or more than one (the console has spawned an interactive process in the background).
The keyboard driver, and the kernel in general, have no concept of the 'active task'. The keyboard driver will give keypress information to any thread that asks for it. When the keyboard driver gets a DEV_READ request, it places it in a queue (=linked list); when it receives a keyboard interrupt, it places the key code in the buffer of all active requests and completes those that have enough keys.
Usually the console server will be the only process that reads from the keyboard (although this is not enforced; if another process reads from the keyboard it is possible that console.exe will miss keypresses). The console server is the one that knows what interactive processes are running, and which one is active. When a key is pressed, it just sends the ASCII code down the pipe for the active console. Each console isn't necessarily associated with one process; a console can have no process (the shell there has exited) or more than one (the console has spawned an interactive process in the background).