Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ttrdc.UUCP
Path: utzoo!linus!decvax!bellcore!ulysses!mhuxr!mhuxn!ihnp4!cuae2!ltuxa!ttrdc!levy
From: levy@ttrdc.UUCP (Daniel R. Levy)
Newsgroups: net.unix-wizards
Subject: Re: Process control and communications
Message-ID: <820@ttrdc.UUCP>
Date: Thu, 3-Apr-86 00:56:50 EST
Article-I.D.: ttrdc.820
Posted: Thu Apr  3 00:56:50 1986
Date-Received: Sat, 5-Apr-86 05:46:57 EST
References: <698@watdragon.UUCP> <2204@brl-smoke.ARPA>
Distribution: net
Organization: AT&T, Computer Systems Division, Skokie, IL
Lines: 46

<Oh oh here it comes.  Watch out boy, it'll chew you up! \
Oh oh here it comes.  The LINE EATER!  [TAH ta-ta]>

In article <2204@brl-smoke.ARPA>, gwyn@brl-smoke.UUCP writes:
>In article <698@watdragon.UUCP> wasaunders@watdragon.UUCP (Parallel Hair???) writes:
>>I would like to set up a time-sharing system (a small one). One of the things
>>I would like to do is to include a multi-user game which I have been thinking
>>of writing. The events during the game are to take place in real time, so
>>one possible architecture for the software would be to have one games master,
>>with player processes forked from it. When someone logs into my system they
>>are given a CI (shell, whatever ....) - if they want to play the game how
>>can I associate the player process with their port, and then restore their
>>CI when they are one playing?
>Assuming you plan to use UNIX:  You can't in general attach a terminal
>to an already-running process, so your best bet is to have a game master
>process that reads a FIFO, socket, or (if you don't have FIFOs or sockets)
>a locked known file to get slave data (part of which for a new slave
>would be information on how to send data back to the player), and start
>up a fresh slave player process when a new player enters the game.

(Also presuming Unix)
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?  (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.)  The
process that the user invoked to notify the master would then sleep
indefinitely, allowing the game process to have uninterfered use of the user's
terminal, until the game ended for that player, whereupon the game program
would kill the sleeping placeholder (or send it a signal to let it voluntarily
exit so the user doesn't see "Killed") to let the user get back to the shell.
Could that work reasonably?

>Games like this have been distributed publicly, for example on USENIX
>tapes.  One that was popular at JHU was called "search".

Is this the same "search" which was posted to net.sources.games a week or
so ago?
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
						vax135}!ttrdc!levy