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