Hi, I need to know how i can make the child process wait for the
parent process to finish. The child process will then take information
from a pipe, then store the information into a file.

Jimmie Barnett

[ Post a follow-up to this message ]

Jimmie wrote:
> Hi, I need to know how i can make the child process wait for the
> parent process to finish. The child process will then take information
> from a pipe, then store the information into a file.

This seems a silly thing to want to do; why do you
want to do it?  If you really must do it, the best I can
think of is to have the child call getppid() in a loop
(presumably a loop that includes some delay) until the
parent process ID changes to 1, meaning that the original
parent has exited and the child has been "adopted" by the
init process.

But why?  If the parent process is filling this pipe
you mention, you can just have the child read it -- if
the parent hasn't written anything yet, the child will
block until some data appears.  In fact, it's sometimes
necessary to have somebody drain data from a pipe: the
O/S is only going to allow a certain amount of data to
accumulate unread, and if more than that is written the
writer will block.  So if your scenario is

Parent creates a pipe, then forks, and the two
processes do the usual dance to get hold of the
proper pipe ends.

Parent writes forty terabytes to the pipe and
then exits.

Child waits for the parent to exit, and then
reads the forty terabytes from the pipe.

... it isn't going to work.  The parent will write for a
while until the pipe's buffer fills up, and then will
block until the child drains some data.  But the child
won't start draining any data until the parent exits,
which it won't do until it's finished all its writing.
The parent won't complete the second step, and the child
will never start the third step.  This is variously known
as a "deadlock" or a "deadly embrace" or a "bad idea."

So: What are you trying to do?

--
Eric.Sosman@sun.com

[ Post a follow-up to this message ]

On Thu, 30 Sep 2004, Eric Sosman wrote:

>      So: What are you trying to do?

Homework?  :-)

--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming",
published in August 2004.

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich

[ Post a follow-up to this message ]

On Fri, 1 Oct 2004, Nick Coleman wrote:

> Yep.  I'm doing two courses related to Unix system programming and I've
> been chuckling away over the last several weeks.  We do a lab on pipes,
> then questions pop up here on pipes.  We do a lab on fork(), and then
> questions pop up here on forking.
>
> Seems Unix courses are taught with the same lecture schedule all over
> the world ;).

Indeed.  :-)

Shameless Plug: you and everyone else on your course should rush
out, today, and buy a copy of my book (preferably via my home page).

--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming",
published in August 2004.

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich

[ Post a follow-up to this message ]

Rich Teer wrote:
> On Thu, 30 Sep 2004, Eric Sosman wrote:
>
> 
>
>
> Homework?  :-)

Perhaps, but what "Jimmie" wanted to do seemed so
bizarre that I have a hard time imagining an instructor
assigning it as an exercise.  "Today's topic, class, is
endangered species.  Here in this cage is the very last
surviving female Lesser Crested Flapdoodle.  Jimmie, take
this meat cleaver and show us just how easily the species
could become extinct."

Is Jimmie trying to do something fiendishly ingenious
and strange, or has he misunderstood his assignment -- or
have teachers grown sillier than I recall?

--
Eric.Sosman@sun.com

[ Post a follow-up to this message ]

In article <cjjo3t$5t6$1@news1brm.Central.Sun.COM>,
Eric Sosman <eric.sosman@sun.com> wrote:

> Rich Teer wrote: 
>
>      Perhaps, but what "Jimmie" wanted to do seemed so
> bizarre that I have a hard time imagining an instructor
> assigning it as an exercise. [snip]
>
>      Is Jimmie trying to do something fiendishly ingenious
> and strange, or has he misunderstood his assignment -- or
> have teachers grown sillier than I recall?

None of the above.  He just misunderstood the reason why his program isn't
working, and did a poor job of restating what he thinks he needs to do to
fix it.

This is actually the second thread he's started in the past two days.  Read
the code he posted in the first thread ("unix pipe problems") and you'll
understand what it's supposed to be doing.

[ Post a follow-up to this message ]

"Wayne C. Morris" <wayne.morris@this.is.invalid> wrote in message news:<wayne.morris-1511D0.
14215301102004@shawnews.wp.shawcable.net>...
> In article <cjjo3t$5t6$1@news1brm.Central.Sun.COM>,
>  Eric Sosman <eric.sosman@sun.com> wrote:
> 
>
> None of the above.  He just misunderstood the reason why his program isn't
> working, and did a poor job of restating what he thinks he needs to do to
> fix it.
>
> This is actually the second thread he's started in the past two days.  Rea
d
> the code he posted in the first thread ("unix pipe problems") and you'll
> understand what it's supposed to be doing.




hahahahaha, you guys are great, yes it is homework but i don't expect
anyone to do it for me  I love this parrell proeccing type of stuff
and want to learn it. let me explain the homework assignment to you..

"program 1.1
Write a program that forks a child process into the background. The
parent then accepts input from its terminal and sends it(through a
pipe) to the background process to store it in a disk file. The parent
process will then exit.

The child process will write it process id into a file and wait for
further communication."

This is exactly what the professor wants us to do, I beleive it would
be easyier to have the child process accept input instead of the
parent but thats my opinion. here is the code i have so far...

#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/wait.h>
#include <string.h>

int MAX = 100;

int main(void)
{

int fd_write;
size_t rc;
int p[2];
int pid;
int wordsize;
char childbuffer[MAX];
char buffer[MAX];

if(pipe(p) < 0)
{
perror("PIPE");
exit(1);
}

if((pid = fork()) <0)
{
perror("FORK");
exit(1);
}
if(pid >0)
{
/*parent*/
printf("Please enter in a word you wish to send through a pipe
to the child\n");
printf("process, the child will then store it to a file names
pipefile\n");

scanf("%s", buffer);
printf("\n");
wordsize = strlen(buffer);
printf("\n\nhere is the word you wrote %s\n\n", buffer);

printf("word size is %d\n", wordsize);

close(p[0]);

rc = write(p[1], buffer , wordsize);
if(rc < 0)
{
perror("Error write to pipe failed");
exit(1);
}
wait((int* )0);
}/*close parent process*/

if(pid == 0)
{
/*child*/
printf("Your in the child prossess, and the # is %d\n",
getpid());

close(p[1]);
rc =  read(p[0], childbuffer, wordsize);
if(rc < 0)
{
perror("error read from pipe failed");
exit(1);
}
printf("here is wordsize %d\n",wordsize);
fd_write = open("pipefile", O_WRONLY | O_CREAT, 0644);
if(fd_write < 0)
{
perror("Error Opening File\n");
exit(1);
}

rc = write(fd_write, childbuffer, wordsize);
if(rc < 0)
{
perror("Error Write Failed\n");
exit(1);
}
printf("before close file function\n");
if(close(fd_write) == -1);
{
perror("Error Close Failed\n");
exit(-1);
}

printf("%s\n", childbuffer);
}
return 0;
}/*close main*/


Once again thanks any help will be appreciated,
Jimmie Barnett

P.S why go and buy your book when I have the internet? 

[ Post a follow-up to this message ]

In article <cf6cc6cc.0410030920.4521264d@posting.google.com>,
jimi_xyz@hotmail.com (Jimmie) wrote:

> This is exactly what the professor wants us to do, I beleive it would
> be easyier to have the child process accept input instead of the
> parent but thats my opinion.

Of course it would be easier to do that.  And even easier to accept input &
write to a file without having any child processes.

But getting user input into a file is not the purpose of the exercise; the
purpose is to do make you write a program that uses a child process and a
pipe.  Whether it does anything *useful* or *sensible* is irrelevant at
this point.  Writing the data into a file just makes it easy for you to
check whether the child received the data correctly.

Programming homework is often like that at the start of a course.  The
tasks are kept extremely simple so you can concentrate on using the one or
two things you've just been taught.  Later exercises should should make
more sense and get more complex, because you're expected to be able to use
everything you've learned in the course.

[ Post a follow-up to this message ]

In article <cf6cc6cc.0410030920.4521264d@posting.google.com>,
jimi_xyz@hotmail.com (Jimmie) wrote:

> P.S why go and buy your book when I have the internet? 

Because books don't go offline, don't crash, and continue to work when your
internet connection temporarily stops working.

Because you can't always find an answer on the internet, and can't always
tell whether the answer you found is the *right* answer.

Because people who have bought the book seem to agree that it's very useful
and informative.

Because by buying the book, you're putting money into the author's pocket,
giving him incentive to write more books that you may find equally useful.

:-)

[ Post a follow-up to this message ]

"Wayne C. Morris" <wayne.morris@this.is.invalid> writes:

> In article <cf6cc6cc.0410030920.4521264d@posting.google.com>,
>  jimi_xyz@hotmail.com (Jimmie) wrote:
> 
>
> Of course it would be easier to do that.  And even easier to accept input 
&
> write to a file without having any child processes.
>
> But getting user input into a file is not the purpose of the exercise; the
> purpose is to do make you write a program that uses a child process and a
> pipe.  Whether it does anything *useful* or *sensible* is irrelevant at
> this point.  Writing the data into a file just makes it easy for you to
> check whether the child received the data correctly.

Right, but this task is unusually silly.  We got to connect some pipes
to format man pages as postscript.

> programming homework is often like that at the start of a course.  The
> tasks are kept extremely simple so you can concentrate on using the one or
> two things you've just been taught.  Later exercises should should make
> more sense and get more complex, because you're expected to be able to use
> everything you've learned in the course.

Yes, our next task was to implement malloc() and friends.

--
Måns Rullgård
mru@mru.ath.cx

[ Post a follow-up to this message ]