Process control and communications

[Doug Gwyn]

In article <820 at ttrdc.UUCP> levy at ttrdc.UUCP (Daniel R. Levy) writes:
>What about a user invoking a process by command from his/her shell which
>sends a signal to the master, which then knows to look to see who logged
>on, and fork a child who can then open() the player's terminal?

Not everybody who logs in is necessarily playing the game;
you end up using IPC to indicate the playing terminal in any case.

I also am not fond of using signals for IPC; they are unreliable.
I see that AT&T proposes to adopt Berkeley-style reliable signals
in the future, though.  I wonder if they solved the signal-during-
fork/exec problem.

By the way, Issue 2 of the SVID is very nice; good work, guys.

>(Or the master could even do the open() and all the I/O itself, but pretty
>soon it would run out of file descriptors, not to mention being VERY busy.)

This is a problem you have to solve anyway.  The master has to send
data to all the screens or their servers somehow.  One of the nice
things about FIFOs is that one can close them and open them again
later (although this is fairly high overhead in this application).

>Is this the same "search" which was posted to net.sources.games a week or
>so ago?

I think so.  They don't allow us to read all newsgroups here.