Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!mouse
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.unix.questions
Subject: Re: A question about read() system call!!
Message-ID: <1991May24.110902.3729@thunder.mcrcim.mcgill.edu>
Date: 24 May 91 11:09:02 GMT
References: <28398698.26968@maccs.dcss.mcmaster.ca>
Organization: McGill Research Centre for Intelligent Machines
Lines: 32

In article <28398698.26968@maccs.dcss.mcmaster.ca>, ashraf@maccs.dcss.mcmaster.ca (Ashraf Mahmoud) writes:

> When a program executes this system call [read()] to read from an
> empty pipeline, shouldn't it return zero ( nothing is read ) and
> passes control to the next statement?  I think it remains stuck
> waiting for something to be put it the pipeline.

You are correct; this is how it's supposed to work.  read() is supposed
to return immediately when there's nothing to read only when the pipe
has only one end (ie, the write end of the pipe has been closed down)
or if the file descriptor has been marked non-blocking, on systems that
support this.

If by "empty" you mean that the program writing to the pipe has closed
the pipe (for example, if it's died), then yes, something is wrong.
Most likely another process has the write end still open.

> How can I overcome this behaviour?  That is making it pass control to
> next statement even if pipeline is empty.

If your operating system supports it, set non-blocking mode on the
pipe.  Look at the fcntl() call for the F_SETFL request, or
I'm-not-sure-where for the FIONBIO ioctl.

If not, you're pretty much out of luck.  You may be able to get by by
setting a timeout to break out of the read.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu