Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: net.unix-wizards
Subject: Re: Process control and communications
Message-ID: <2414@brl-smoke.ARPA>
Date: Sat, 5-Apr-86 23:13:54 EST
Article-I.D.: brl-smok.2414
Posted: Sat Apr  5 23:13:54 1986
Date-Received: Wed, 9-Apr-86 21:29:13 EST
References: <698@watdragon.UUCP> <2204@brl-smoke.ARPA> <820@ttrdc.UUCP>
Reply-To: gwyn@brl.ARPA
Distribution: net
Organization: Ballistic Research Lab (BRL)
Lines: 27

In article <820@ttrdc.UUCP> levy@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.