OSDev.org

Greetings everyone,

I have some theoretical questions about terminals and processes. Let's assume the following environment:

Suppose that an OS has one terminal for the whole system which processes can connect on it. Initially, there is only one process in the system (let's call it process0) and that is, by the way, connected on the terminal.

For instance, process0 will be (always) the "active process" (process that is interacting with the user) and every time that a keyboard key has been pressed, it will be put in a "tty read queue" that process0 can read.

After some execution, at some point process0 decided to create a child process (process1):
As illustrated above, after the fork() system call, both processes (process0, process1) perform I/O operations on the terminal.

Regarding this situation my questions are:

Question 1: Each process has to have its own "tty read queue" and "tty write queue" or can be one of them per terminal?
Question 1 Remark: It seems to me if each process has its own queues, some race conditions can be avoid and therefore, the terminal implementation can be more secure and parallel. However, if each process has its own tty queues this is a BIG waist of memory.

Question 2: As I said above, the keyboard keys which have been pressed are copied to a "tty read queue" and the active process can somehow read them. When there are two processes "running" in a terminal (like the example above) and there is no way to decide which process is the "background process" (process were not created like process1 & process0), every time that a process is scheduled to be executed it becomes the "active process". If so, a big messy comes in, because the keyboard driver will put the pressed keys on the "tty read queue" of the active process. However, maybe the "active process" is not waiting any keyboard input but another process, that is the really active process (process that is interacting with the user), is. The question is: how is it possible to decide which is the "active process" in this situation?

I hope that you get the questions.

Thanks in advance,

Pedro H. Penna

Firstly Whitebird wrote: Question 1: Each process has to have its own "tty read queue" and "tty write queue" or can be one of them per terminal?
Question 1 Remark: It seems to me if each process has its own queues, some race conditions can be avoid and therefore, the terminal implementation can be more secure and parallel. However, if each process has its own tty queues this is a BIG waist of memory.

Let's talk about how existing Posixy OS's do this. After a fork() each process has a set of file descriptors that refer to the same files. In fact the file descriptors refer to the same file control blocks which means that they will 'race' while reading the keyboard. (Incidentally it also means that if one process does an lseek() the other process will read() from the new position). The reason this doesn't matter is that after a fork() the parent usually does a wait() until the child terminates. The child receives all the keys until it terminates and then the keys go to the parent again. The queues are in the drivers so there is only one queue.

then Whitebird wrote:Question 2: As I said above, the keyboard keys which have been pressed are copied to a "tty read queue" and the active process can somehow read them. When there are two processes "running" in a terminal (like the example above) and there is no way to decide which process is the "background process" (process were not created like process1 & process0), every time that a process is scheduled to be executed it becomes the "active process". If so, a big messy comes in, because the keyboard driver will put the pressed keys on the "tty read queue" of the active process. However, maybe the "active process" is not waiting any keyboard input but another process, that is the really active process (process that is interacting with the user), is. The question is: how is it possible to decide which is the "active process" in this situation?

Imagine you are a tty driver and some process asks for a key. You give it a key. Then a process asks for a key. You give it a key. As long as the process has a valid file descriptor you your resource (this would be checked at open() or the implicit dup() during the fork() ), you just give it keys. As I said before it works in practice because the parent wait() s for the child.

Another approach is the focus ring. Instead of process polling for key, the "gui manager" know which widget is in focus, resolve its process id and post an event to the process, note that this also work for text mode UI, where the focus navigation mechanism may differ(e.g. CTL-Fx to switch tty on linux).

This reminds me of why people should use proper thread titles. More backgrounds in there.

gerryg400,

So, if I can assume that the parent process will always wait for his child things are much more easier than I imagined... I was thinking what happened in this kind of situation: I've simulated it on my Linux but I couldn't define a behavior for it... Anyway, I suppose that I can assume the same thing when writing on terminal. Can I?

Thans gerryg400 and bluemoon by the answer it really helped me to clarify things!

Combuster, I'm really sorry about that. Before creating this new thread I've searched on the forum but I couldn't find anything while I was reading the threads' titles. Anyway that thread was really helpful too.

Regards,

Pedro H. Penna