Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!pacbell!att-ih!ihnp4!inuxc!iuvax!bsu-cs!cfchiesa
From: cfchiesa@bsu-cs.UUCP (Christopher Chiesa)
Newsgroups: comp.os.vms
Subject: Re: Process Communication.
Message-ID: <2359@bsu-cs.UUCP>
Date: 14 Mar 88 18:37:00 GMT
References: <8803131101.AA27859@ucbvax.Berkeley.EDU>
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 53
Summary: You really don't have a problem.  A headache MAYBE.

In article <8803131101.AA27859@ucbvax.Berkeley.EDU>, MICHAL@UKANVAX.BITNET writes:
>  While in the main process, I SPAWN/NOWAIT a process that does something
> completely different from what I am doing in the main process. The problem
> arizes when the SPAWNed subprocess wants an interactive input (and it must
> be interactive). Can the subprocess `hang' the main process until it receives
> what it wants ? If not, what would you suggest ?

I've experienced the situation you describe, and it isn't too bad IF you can 
keep track of what you're doing.  Prompts-for-input, and the corresponding 
"destination" of what you type in response, tend to get intermingled and can
mislead you if you're not alert.

I frequently have to enter received-mail information into a database (highly 
interactive).  In order to avoid having to go through my mail, note the informa-
tion, and then exit out and run the database, I will SPAWN/NOWAIT a subprocess
from the MAIL> prompt, and enter information into the DB at the same time as I
go through the actual MAIL.  It gets tricky, though, trying to decide which
program I'm "talking" to when I have both prompts on the screen!

The prompts come up on the screen, one after the other, and their corresponding
input requests are queued for you to "type back at."  However, each prompt 
places the cursor where IT wants it, NOT where the pending-input queue situa-
tion would have it.  An example: I have the following on my screen:
 
DB> 
MAIL>

My cursor is sitting at the MAIL> prompt because that was the latest output to
the terminal, but I haven't yet satisfied the preceding input request, which is
that associated with the DB> prompt.  So the next command I type, will go to the
DB program, even though the cursor is sitting at the MAIL> prompt.  This kind of
thing could really confuse someone not expecting it.
 
This is the basic scenario when you have an interactive, /NOWAIT-ed subprocess.
If you keep your wits about you, and your input/output prompt/respsonse is line-
oriented, it isn't TOO bad.  You do have more of a problem when your two pro-
cesses are painting (i.e. overwriting!) each other's screen space, or moving 
the cursor, or performing some specialized form of input (such as queuing a
separate I/O request for EACH CHARACTER), but it all revolves around the prin-
ciple of "first come, first served, in the ORDER OF FIRST APPEARANCE (time),
rather than ORDER OF FINAL LINEUP (physical end result) of prompts etc. 

Hope this is somewhat helpful.  If *I* can do it, chances are *you* can too.

Chris Chiesa
Senior, CS Dept
Ball State University
Muncie, IN
-- 
<><><><><><><><><><><><><><><><><><><><><><><><><><><><> Chris Chiesa <><><><><>
<> {ihpn4|seismo}!{iuvax|pur-ee}!bsu-cs!cfchiesa                              <>
<> cfchiesa@bsu-cs.UUCP                                                       <>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>