Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!linac!mp.cs.niu.edu!rickert
From: rickert@mp.cs.niu.edu (Neil Rickert)
Newsgroups: comp.unix.questions
Subject: Re: Questions regarding PIPES and SHARED MEMORY.
Message-ID: <1991Jun15.142847.23459@mp.cs.niu.edu>
Date: 15 Jun 91 14:28:47 GMT
References: <285926A1.13114@maccs.dcss.mcmaster.ca>
Organization: Northern Illinois University
Lines: 63

In article <285926A1.13114@maccs.dcss.mcmaster.ca> ashraf@maccs.dcss.mcmaster.ca (Ashraf Mahmoud) writes:
>Q1. The following code makes child read from pipe in a nonblocking manner. But
>    it seems, when I run the code, that not all messages sent by parent are 
>    received by child. Some are lost. The child is supposed to receive five 

  --- segment of code for parent ---

> for(i=0; i<5; i++) 
> { 
>  sprintf(buf,"Parent Calling Child %d Itr = %d",pid1,i);
>  write(fdes[1],buf,strlen(buf)+1);
> }

  --- segment of code for child ---

> close(fdes[1]) ;
> for(i=0; i<1500; i++){
>     strcpy(buf,"");
>     read(fdes[0],buf,80);
>     printf("\n Read succeeded i = %d ",i);
>     printf("\nChild> %s",buf);

 You are reading 80 bytes each time.  Since your writes are for less than
80, your first read may include part of the second write string.  However
when processing the data you read, you are ignoring everything past the
'\0' which terminates the first string written.

 I believe you are confused about the meaning of "non blocking".  This only
means that your process will not wait if there is nothing to read.  It
does not guarantee that your process will always be scheduled (i.e. given
CPU time) as soon as there is data to read.  It is quite conceivable that
the writing process may do two or more write operations during its time
slice, before relinquishing control of the CPU.  In this case your read
could read up to 80 bytes, which might contain parts of 2 or more written
records.

 It is, in principle, possible also for the writing process to write only
part of its output before losing its time slice.  In practice Unix
implementations do not permit this with such small buffers, but depending
on that behavior is bad programming.  If, for example, the writing process
were to write 10K bytes at one shot, it would surely be interrupted in the
middle, and the reading process would read only a partial record at the
next read.

 To properly handle this the reading process must keep track of how many
bytes have been read but not yet processed.  It should expect that any
record read may not be complete in which case the next successful read
will begin with the continuation of that record, and even that continuation
need not be complete.  It should also expect that following the end of one
record the same read operation may have retrieved part or all of the next
record.  (By "record" here, I just mean the data output in a single "write"
in the parent process).

--
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940
-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940