Is it possible to have a single unix process that controls multiple terminals?

Question

So, typically the model that I'm familiar with is that if you want to have some way for multiple users on different terminals to interact with the same process, you would write client programs that interact with a single server process.

My question is: Is it possible/reasonable for each client to somehow attach directly to that single process rather than having to write a client/server program? My goal is to avoid the complexity of serialization over a sockets layer, and just have all the terminals communicate using shared datastructures in memory.

I'm guessing that it would be pretty tricky, and perhaps impossible under unix, but I'd like to hear if anyone has ever done or seen anything like this, and what the requirements might be, and whether or not the decrease in serialization complexity was outweighed by other disadvantages of this approach.

Answer 1

Terminal emulator is already a client. Simply open tty file.

Example

$ gnome-terminal --tab-with-profile=main --command="env sleep 1d" --tab-with-profile=main --command="env sleep 1d"
$ ps --ppid $PPID -ly
S   UID   PID  PPID  C PRI  NI   RSS    SZ WCHAN  TTY          TIME CMD
S  1000  2151  2082  0  80   0  5208  2200 wait   pts/1    00:00:02 bash
...
S  1000  4500  2082  0  80   0   284  1051 hrtime pts/8    00:00:00 sleep
S  1000  4501  2082  0  80   0   280  1051 hrtime pts/9    00:00:00 sleep
$ echo -e 'tab1: \e[31mWorking!\e[39m' > /dev/pts/8
$ echo -e 'tab2: \e[31mWorking!\e[39m' > /dev/pts/9

Answer 2

I would reverse the point of view: "for each client to somehow attach directly to that single process" is a sort of nonsense in unix (and not only). Even if you don't want to use sockets, you have nevertheless to write a "client" program to attach to a shared memory object published by the server, or a named pipe, or even a plain file. The medium you use to communicate with the server may vary, but in general the unix' architecture encourages to assign the "server" function to a separate process (or more). So, what you probably are looking for is a sort of "light" inter-process communication, with few or no arbitration between counterparts. If the data integrity is not a problem, you may use a block of shared memory exposed by the server, where all the clients (yes, you have to write a "client" program anyway) may attach to read data as a plain block of memory. If you need some sort of data integrity, or if the clients sometimes need to also write something to the shared memory, you can use a semaphore or mutex to synchronize accesses to the data structures inside the shared block. There are many drawbacks in this solution, it takes sense only if the "shared database" doesn't change often, or if data integrity is not a requirement, or also if the overhead due to mutex/semaphores is acceptable.

For the sake of completeness, I'll tell how we were used to do at the good old times of serial terminals: at that time, the server process itself handled many terminals directly. It's a matter of opening the terminal lines (one or more /dev/ttyXXX devices), configure them and have a "main loop" in which each channel (i.e. file descriptor) is listened by a "select" system call or similar. Of course, the terminals were locked to the specific application and the user could do only what the application let him/her do.

EDIT: a common way to avoid writing a client program is make the server implement a simple text-based, line-oriented protocol on a tcp port. The client is... telnet! Of course, it's a very rude solution, but in many situations (e.g. debugging, maintenance...) it's enough.

Answer 3

You found the answer by yourself! You can use share memory segments for process to communicate. shm_open is a good entry for POSIX shared segments, you may also use shmget SYSV shared segments, or even mmap shared memory mapping.

There will be some tricky parts of course, because you need to clearly defined how the shared structure is shared. It is common to use some kind of semaphores or things like that to synchronize access to the structure. And will probably won't save you from the need to define a kind of protocol/serialization...