You just need to click or middle-click the link (to open in a new window) and press the Play button you see, and watch how the code was written as if it was a text-based movie for the source code. It is hosted on the Archive.org website so it should not be down.
ashishkumar4 wrote:I have made such a thing called taskSleep() which just makes the task 'sleep' from which it was invoked, indefinitely until some I/o operation for it arrives. Like for example, I do this:
My func()
{
print some thing.
lock the keyboard input (MUTEX and iolock (a thing I made) )
sleep()
///**** from here the task ends for indefinite time, and other tasks are processed as the task gots removed from the queue***///
getline(something)
print it
}
as soon as I press a key, the interrupt Manager (for keyboard for example) puts the task which locked it to highest priority so as the task gets executed Immediately. Thus a Task like GUI app or something of high priority is removed from the queue until input arrives from the user if it required it, and wakes up almost instantly after the interrupt handling of the input interrupt (int 1 for keyboard, which writes to an input buffer)
Is everything right? it seems to work fine on qemu because :/
Thanks
There are several ways to decide to which application to send the data and you should consider them. One is to send user events to the process to which window or text console (in case of pure text-mode windows) is focused and is in the foreground at the top of the stack of windows on screen.
The other is send them to the process that requested data.
The other is have the kernel send data or messages to an application for some reason.
The other is that an application queries the kernel for the list of existing processes and have it select a process ID and a handle for inter-process communication.
In each case, you must know who sends the data (another application, kernel, which device, scheduler, subsystem, etc...) and by which process it must be received.
You could have a message queue for the process and a protocol and an implementation criteria of how to send the messages. Usually for the keyboard, the messages go to the currently selected text console, and for the mouse they go to the application the mouse is moving over taking into account the 2D window or object area. For task scheduling you could reserve more CPU time slices to the currently selected window or console and also for background processes that have higher priority than the others. For devices you would have interrupts and DMA signal completion or requests to give or receive more data. You could accompany every command with a structure that indicates the ID of the process and the thread that initiated it so that you know where to send/receive the data (which application) and also whether to wake it and which one.
So you should have different input/output buffers depending on the services and APIs each application uses. The default buffers would be for keyboard, mouse, disk and network data, as well as some form of structure for storing or sending data from/to multimedia devices, and of course a virtual screen or a handle to the raw video memory. You would need to have all those structures for each process.