waagen@cod.NOSC.MIL (Don E. Waagen) (12/30/88)
I'm trying to have two processes communicate via a pipe (stdout), like A | B but with a small difference. Process A will never die (i.e. the connection will never be closed). What I would like to do is have the fread and getchar() calls of process B sense or think that it is seeing the pipe close (i.e. an EOF character returned by the calls) without closing the connection. I have tried flushing EOT characters (^D) to process B, but this doesn't help. The fread call in process B remains blocked. I've also tried having process A's standard out dup'd and then closing standard out, and then duping the duplicate back to 1 (standard out); no luck. It seems the dup'd file descriptors share status fields. My Question: What do the standard library calls use to determine end-of-file. I really need to be able to do this, for a process to know when an end of transmission has occured. Thanks in advance -- Don Waagen
ark@alice.UUCP (Andrew Koenig) (12/30/88)
In article <1345@cod.NOSC.MIL>, waagen@cod.NOSC.MIL (Don E. Waagen) writes:
->
-> I'm trying to have two processes communicate via a pipe (stdout), like
->
-> A | B
->
-> but with a small difference. Process A will never die (i.e. the connection
-> will never be closed). What I would like to do is have the fread and getchar()
-> calls of process B sense or think that it is seeing the pipe close (i.e. an EOF
-> character returned by the calls) without closing the connection.
Sorry, but it's completely impossible in most systems.
--
--Andrew Koenig
ark@europa.att.comles@chinet.chi.il.us (Leslie Mikesell) (12/30/88)
In article <1345@cod.NOSC.MIL> waagen@cod.nosc.mil.UUCP (Don E. Waagen) writes: > > I'm trying to have two processes communicate via a pipe (stdout), like > > A | B > >but with a small difference. Process A will never die (i.e. the connection >will never be closed). What I would like to do is have the fread and getchar() >calls of process B sense or think that it is seeing the pipe close (i.e. an EOF >character returned by the calls) without closing the connection. If you have SysV style FIFO's (named pipes) the programs can actually do the open/close. In any case, though, you could send an agreed-upon character or sequence as a terminator. Or is the real problem the stdio buffering keeping B from seeing anything until a block is filled and flushed? If that is the case, just use read() and write() instead of the buffered versions. Les Mikesell
gregg@ihlpb.ATT.COM (Wonderly) (12/31/88)
From article <8629@alice.UUCP>, by ark@alice.UUCP (Andrew Koenig): > In article <1345@cod.NOSC.MIL>, waagen@cod.NOSC.MIL (Don E. Waagen) writes: > -> > -> I'm trying to have two processes communicate via a pipe (stdout), like > -> > -> A | B > -> > > Sorry, but it's completely impossible in most systems. True, EOF on a pipe only happens when all read fd's are closed... An alternative is to send a signal from A to B, interupting the read. This is not a pretty solution at all, but does provide the necessary functionality. -- It isn't the DREAM that NASA's missing... DOMAIN: gregg@ihlpb.att.com It's a direction! UUCP: att!ihlpb!gregg
gregg@ihlpb.ATT.COM (Wonderly) (12/31/88)
In article <9305@ihlpb.ATT.COM>, I said > True, EOF on a pipe only happens when all read fd's are closed... Which should have said... True, EOF on a pipe only happens when all WRITE fd's are closed... -- It isn't the DREAM that NASA's missing... DOMAIN: gregg@ihlpb.att.com It's a direction! UUCP: att!ihlpb!gregg
mhw@wittsend.LBP.HARRIS.COM (Michael H. Warfield (Mike)) (01/03/89)
In article <1345@cod.NOSC.MIL> waagen@cod.nosc.mil.UUCP (Don E. Waagen) writes: > I'm trying to have two processes communicate via a pipe (stdout), like >but with a small difference. Process A will never die (i.e. the connection >will never be closed). What I would like to do is have the fread and getchar() >calls of process B sense or think that it is seeing the pipe close (i.e. an EOF >character returned by the calls) without closing the connection. >I have tried flushing EOT characters (^D) to process B, but this doesn't help. >The fread call in process B remains blocked. >I've also tried having process A's standard out dup'd and then closing standard >out, and then duping the duplicate back to 1 (standard out); no luck. It >seems the dup'd file descriptors share status fields. >My Question: What do the standard library calls use to determine end-of-file. >I really need to be able to do this, for a process to know when an end of >transmission has occured. Point #1 - There is no "end of file" charracter. The EOT character is interpreted (in cooked mode) by the tty device driver and translated into an end of file on that file descriptor. In order to get an end of file when reading a pipe ALL fid's connected with that pipe and open for write must be closed. The standard library calls get the end of file status from the system. i.e. The file system drivers inform the application that you are at end-of-file. I can't think of any easy way to signal the reading process of an end-of- file and still be able to use that pipe later. Maybe someone in the wizards group can come up with an idea. This would seem to have some interesting possiblilities. BTW: What does process "B" do when it gets the end of file? Does he quit? This would cause a "broken pipe" to process "A". If you have source control over both processes, your best bet is probably to use some sort of "in-band" signaling between the processes. i.e. A certain character sequence signals your interprocess "end-of-file" (EOT ^D would work nice) and then support and escape sequence to transfer a legitimate EOT charracter (\^D) and one for the escape character (\\). This requires filtering all of your data but that may be easier than faking out a real end-of-file. If you have to use out-of-band signaling then you probably need to resort to interprocess signals ala SIG_USR1 and SIG_USR2. --- Michael H. Warfield (The Mad Wizard) | gatech.edu!galbp!wittsend!mhw (404) 270-2123 / 270-2098 | mhw@wittsend.LBP.HARRIS.COM An optimist believes we live in the best of all possible worlds. A pessimist is sure of it!