sockets and pipes.... 5193

Captain Dondo I worked on a system that ran a lot of terminals (advanced telephone sets connected to Dialogic boards), switches (more Dialogic boards), etc.

What we did was to have an instance of a process called an Interface Server working with each terminal. We had other processes that could be spun off by an IS, such as an instance of a User Agent. In turn the UAs could spin off applications, such as a call processor.

At another level, there were resources, such as a connection server, a data server, a process server... .

When we first devised the system, these were all designed as finite state machines that dequeued UNIX messages. Later on, we had to distribute the system over multiple computers not necessarily co-located, so we used sockets and IP (probably TCP-IP, but I no longer recall). But the IPC the system used was hidden from the writers of the programs of everything but the implimentor of the Process Server that hid all the annoying details. The UA, for example, did not do fork() and exec(); it sent a suitable message to the PS and it did the fork() and exec() and managed the IPC.

Each finite state machine, be it a server or an application, just hung in a loop dequeuing messages, acting on them in the order received, and possiby sending other messages. No deadlocks unless the internal implimentation of the UNIX messages filled up the input queues of the various processes. Fixing that was a bit tricky, but I would imagine with the large memory sizes these days, that would not have been a problem. We solved it another way then that I will not bore you with.

Is you might consider the IPC from System V. man msgsnd, man msgrcv, man msgctl

I think if I were going to do it over now (15 years later), I would try to use TCP-IP, but keep all the processes as finite state machines dequeueing the messages.

In your case, I would have a process waiting for each sensor (and perhaps another one waiting to activate any executor (or whatever you call the output device corresponding to a sensor as an input device)), and these processes would send messages to the main process which is also just sitting around waiting for messages. Thus, the sensor programs would be doing the waiting and thus not delaying or deadlocking the main process that processes its messages as fast as it can.

A nice thing about this is that if a sensor or the buttociated process dies, deadlocks, etc., the main process just does not get any messages from it anymore. It does not deadlock the main process. The main process can have watchdogs in it and take remedial action if an expected message does not arrive "in time."

-- .~. Jean-David Beyer Registered Linux User 85642. V PGP-Key: 9A2FC99A Registered Machine 241939. ^^-^^ 13:20:00 up 7 days, 11:42, 3 users, load average: 4.32, 4.23, 4.19