Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!pryor
From: pryor@uunet.UUCP (Paul Pryor)
Newsgroups: comp.unix.wizards
Subject: SYS V Rel 3.2 (3B2) asynchronous reading from two or more inputs
Keywords: asyncronous SYSV 3B2
Message-ID: <244@imspw6.uunet.UUCP>
Date: 14 Feb 90 00:22:31 GMT
Organization: IMS Inc., Rockville MD
Lines: 51

This seem to be so simple a question, but I could not resolve it, even
after reading every RTFM's I could find anywhere !

I ran into a serious flaw in SYSV Rel 3.2, if it could be called a flaw
(probably never would be the last one !). Here's my simple problem:

	creates two pipes, called pipea & pipeb using pipe(2)
	forked using fork(2)

	child dups (using dup2(3)) pipea with stdout, pipeb with stdin
	child execl's a program (now a background process)

	parent sets pipea & stdin to O_NDELAY by using fcntl(2).
	parent goes into a busy loop
		read from pipea using read(2). If there are bytes
		returned from read(), it writes them out to stdout

		read from stdin using read(2). If there are bytes
		returned from read(), it writes them out to pipeb

From above algorithm, I immediately ran into two serious problems:

a) the read(2) call, if pipe is empty, but not closed, returns -1. Since
I'm on SYS V Rel 3, I'm really stuck ! Does SYS V Rel 4 fixes this little
itty bitty problem ? I, instead, depended on stdin being closed as the
indication when to terminate and break out of the busy loop. This worked
well enough.

b) the biggest and worst problem is that I had to go into a busy loop
reading from two asyncronous input sources ! The signal(2) man page
says that SIGPOLL is used only with STREAMS. And I don't want to get
really mixed up with IPC's pipes. They are not as well documented as
I would like them to. And same goes for STREAMS, and I don't even
know if I could implement pipes roughly using STREAMS thanks to lack
of documentations I have on hand.

I didn't want to put in sleep()'s because I wanted to create time stamps
for groups of bytes read in from either sources.

Right now the program as described above works, but its a veritable cpu
hog. Running multiple instances of the same program immediately brought
AT&T 3B2/600G down to its knees.

How do I find my way out of this predicatement ?

Thanks, guys & gals !!!

Paul.
-- 
Paul T. Pryor (uunet!imspw6!pryor)
Integrated Microcomputer Systems, INC. Rockville, MD