[comp.os.vms] Process Communication.

MICHAL@UKANVAX.BITNET (03/13/88)

I am faced with the following problem and I would appreciate anyone
sending me a note of hope saying that I really do not have a problem.
Well, here it is :

 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 ?

+-----------------------------------------------------------------------------+
|  Michal Chmielewski             KKKK        KKK    UUU       UUU            |
|  University of Kansas            KKK      KKK      UUU       UUU            |
|  Academic Computing Center       KKK     KKK       UUU       UUU            |
|  Sunnyside & Illinois            KKK    KKK        UUU       UUU            |
|  Lawrence, Kansas  66045         KKK   KKK         UUU       UUU            |
|  913-864-0443                    KKK  KKK          UUU       UUU            |
|                                  KKKKKK            UUU       UUU            |
|  bitnet:                         KKK  KKK          UUU       UUU            |
|       michal@ukanvax.bitnet      KKK   KKK         UUU       UUU            |
|                                  KKK    KKK        UUU       UUU            |
|       michal@ukanvm.bitnet       KKK     KKK       UUU       UUU            |
|                                  KKK      KKK       UUUUUUUUUUU             |
|                                 KKKK        KKK       UUUUUUU               |
+-----------------------------------------------------------------------------+

carl@CITHEX.CALTECH.EDU (Carl J Lydick) (03/14/88)

 > I am faced with the following problem and I would appreciate anyone
 > sending me a note of hope saying that I really do not have a problem.
 > Well, here it is :
 > 
 >  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 ?

Sort of.  QIO[W]s to a given terminal device are processed on a first  queued,
first  served basis.  This means that if both the main process and the spawned
process want to read from your terminal, and the spawned  process  queues  its
I/O  request  first, the main process won't do anything until you've satisfied
the subprocess's request, then that of the  main  process.   If  this  doesn't
answer  your  question,  please  repost it, being more specific regarding your
problem.

cfchiesa@bsu-cs.UUCP (Christopher Chiesa) (03/15/88)

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                                                       <>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>