OSDev.org

Hi all,
i have a question about multitasking:

How to handle task that need input from keyboard and task that doesn't need it. For example, if i have 3 tasks: shell, idle, and another taks that doesn't need the keyboard. Now with that scenario probably when the user is writing a command the scheduler change tasks several times, how i will be sure that the input goes to the correct task.

And what if two tasks need to use the keyboard? For example if inside the shell i launch a new task (probably a program) and it need to interact with the user via keyboard/mouse, how i handle that? The shell task should sleep until the task has finished?

Erm... no.

Only one task can be active at a time. If you have a MS-DOS like system, it's the currently running program. On a multi-terminal system, it's the currently running program in the currently active terminal. On a GUI, it's the currently active window.

When you type, interrupts are generated. Those stop the currently running task, and give control to the interrupt handler / keyboard driver, which passes the keystroke to the input buffer of the currently active task, and returns.

I.e., the whole thing has nothing to do with the scheduler.

Or, another way of putting it. The keystrokes will go to whatever task requests them. An OS will issue requests to the kernel (normally via the read and write system calls) when it needs to input data or output it. The kernel knows which task made the call, so it knows which task to direct the keystroke to.

Uh... what?

The task does a read(), and the kernel provides the task with keystrokes?

Are you trying to intentionally confuse the OP?

Um - no. How else is the system to know that a task wants a keystroke? Is it supposed to guess? Or just send all keystrokes directly to the task whether it is waiting for input or not?

In all the OSs that I am familiar with the task will issue a read() request to STDIN, which normally refers to the console device, and then will block until the kernel sends it a character. What's confusing about that? The kernel, via the keyboard device driver, will have processed the raw key codes and translated them into characters which it places on a queue ready for delivery.

It gets a bit more complicated when you have several active tasks, as the kernel has to keep track of which console is active and whether there might be a question of who the keystroke was intended for, but I didn't want to confuse the OP with virtual consoles. In the cases that the OP was discussing there is only one active task so it is not so complicated.

In my OS, and probably also in DOS-boxes in Windows, each console process gets it's own keyboard buffer. Read of stdin goes to the local keyboard buffer. The IRQs from the keyboard itself sends the keystrokes to the process that has input focus.

I use the same concept for the screen. Output will go to a local, per process, buffer. When the video mode is text, the output buffer will be mapped to the physical text-mode buffer in the process that has input focus, and to a RAM location when it doesn't. When using graphics mode, it is a little more complex due to limitations in video-hardware. Then all graphic operations for screen will always be written to the RAM location, and additionally also to the physical video-hardware when it has input focus.

And now we're back to the worst case: only one post needed to promote your system.

And what if two tasks need to use the keyboard? For example if inside the shell i launch a new task (probably a program) and it need to interact with the user via keyboard/mouse, how i handle that? The shell task should sleep until the task has finished?

In all designs, there's only one owner of any device. If a keyboard is distributed between two consoles, a window manager takes the keypresses, forwards them to one of the controlled processes unless it's, for example, a combination like ALT+TAB. Each of the client shells owns the resulting virtual keyboard (and other parts of the "terminal") that the window manager provides.

The same goes with child processes started from the shell: the calling process forwards all the keypresses to the client process until it detects that the client process has stopped. On unices this would be done by actually sharing a file descriptor, but the semantic ownership still goes to the child process - as long as it runs the shell has absolutely no right to access the input and output.

Strictly speaking, if he was promoting his system, he promoted Windows simultaneously .

iansjack wrote:Um - no. How else is the system to know that a task wants a keystroke? Is it supposed to guess? Or just send all keystrokes directly to the task whether it is waiting for input or not?

In that picture, what happens if multiple tasks did send a read() on their STDIN?

The keystroke gets forwarded to the one task that currently has control of the keyboard - the active one. The others are blocking until they become active - in the point-and-click / alt-tab meaning of "active", not the scheduler one. If you have a terminal waiting for user input, but are currently typing in a different terminal, that first one will block forever unless you - the user - switch back to it.

Ok. I was mistaken.