#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>

int main()
{
pid_t pid=fork();
if ( pid == 0 )
{
write(1,"I am Child",10);
fflush(stdout);
_exit(0);
}
else if (pid > 0)
{
write(1,"I am Parent",11);
fflush(stdout);
exit(0);
}
else
{
printf("fork failed");
}
}

now, if i run ./a.out > op, in a multiprocessor system, the content of
the file is
I am Childt

Note the 't' at the end of the string. Its obvious that parent data was
overwritten by child.
I want to know if this behaviour is as per UNIX standards.

Thanks
anoop

[ Post a follow-up to this message ]

anoop.vijayan@gmail.com wrote:

>         write(1,"I am Child",10);
>         fflush(stdout);

> now, if i run ./a.out > op, in a multiprocessor system, the content of
> the file is
> I am Childt
>
> Note the 't' at the end of the string. Its obvious that parent data was
> overwritten by child.
> I want to know if this behaviour is as per UNIX standards.

No, the result is totally arbitrary. You are combining buffered and
unbuffered I/O the same file descriptor. This causes undefined behaior.

DS

[ Post a follow-up to this message ]

On 9 Jun 2006 14:37:17 -0700
anoop.vijayan@gmail.com wrote:

> now, if i run ./a.out > op, in a multiprocessor system, the content of
> the file is
> I am Childt
>
> Note the 't' at the end of the string. Its obvious that parent data
> was overwritten by child.
> I want to know if this behaviour is as per UNIX standards.

What were you expecting to happen? Both the child and parent open the
*same* file for writing at the *same* time. To solve this, you must use
semaphores to control the write access.

--
Regards, Ed                      :: http://www.bsdwarez.net
just another bash hacker
Say NO to LONGHORN/VISTA -- google this: "how microsoft is selling
out the public to please hollywood"

[ Post a follow-up to this message ]

ed wrote:

> What were you expecting to happen? Both the child and parent open the
> *same* file for writing at the *same* time. To solve this, you must use
> semaphores to control the write access.
>

As per "Design of Unix OS" by Bach, the file offsets across fork are
shared by parent and child and these process never read or write the
same file offset values. I wanted to know if this holds for a
multiprocessor system

[ Post a follow-up to this message ]

<anoop.vijayan@gmail.com> wrote in message
news:1149890038.433064.68910@j55g2000cwa.googlegroups.com...
> ed wrote:
> 
>
> As per "Design of Unix OS" by Bach, the file offsets across fork are
> shared by parent and child and these process never read or write the
> same file offset values. I wanted to know if this holds for a
> multiprocessor system
>

What you don't seem to understand is that the parent and child have the
same offset a the time of the fork, but this offset is handled independently
by parent and child.  One does not update the other's offset.  You are only
partly safe by fseek()ing or lseek()ing to the end of the file before
writing.
You are still exposed to one process overwriting the other processes output
unless you use something like file-locking to prevent simultaneous writes.

--

Fletcher Glenn

[ Post a follow-up to this message ]

>>> What were you expecting to happen? Both the child and parent open the 
>
>What you don't seem to understand is that the parent and child have the
>same offset a the time of the fork, but this offset is handled independentl
y
>by parent and child.

Why?  This is a shared file descriptor.  The parent and child did
not both open the same file in the original posting.  They share
the same already-open file descriptor.

Now, it could be that the fflush(stdout) messed with the file
pointer.  You aren't supposed to mix buffered and unbuffered output
on the same file descriptor.

>One does not update the other's offset.  You are only
>partly safe by fseek()ing or lseek()ing to the end of the file before
>writing.
>You are still exposed to one process overwriting the other processes output
>unless you use something like file-locking to prevent simultaneous writes.

On a shared file descriptor, I don't see why this is necessary if neither
process is doing any seeking and both are doing write()s.

Gordon L. Burditt

[ Post a follow-up to this message ]

anoop.vijayan@gmail.com wrote:
> ed wrote:
> 
>
> As per "Design of Unix OS" by Bach, the file offsets across fork are
> shared by parent and child and these process never read or write the
> same file offset values. I wanted to know if this holds for a
> multiprocessor system
posix guarantees atomic write(2)s on a filedescriptor. You do
have some fflush() statements there which works on FILE* not
filedescriptors (thoug underlying a FILE* is a descriptor)
Mixing these are dangerous.

It should be noted that linux had(has?) a bug regarding just this -
http://lwn.net/Articles/180388/ (same applies to shared fds by fork())

[ Post a follow-up to this message ]

The file descriptor isn't incremented till just before write() returns.
anoop.vijayan@gmail.com wrote:
> #include <sys/types.h>
> #include <unistd.h>
> #include <stdio.h>
>
> int main()
> {
>     pid_t pid=fork();
>     if ( pid == 0 )
>     {
>         write(1,"I am Child",10);
>         fflush(stdout);
>         _exit(0);
>     }
>     else if (pid > 0)
>     {
>         write(1,"I am Parent",11);
>         fflush(stdout);
>         exit(0);
>     }
>     else
>     {
>         printf("fork failed");
>     }
> }
>
> now, if i run ./a.out > op, in a multiprocessor system, the content of
> the file is
> I am Childt
>
> Note the 't' at the end of the string. Its obvious that parent data was
> overwritten by child.
> I want to know if this behaviour is as per UNIX standards.
>
> Thanks
> anoop

[ Post a follow-up to this message ]

Jolting <hunterlaux@gmail.com> wrote:
> The file descriptor isn't incremented till just before write() returns.

write() is an atomic function:

http://www.opengroup.org/onlinepubs...ions/write.html
http://www.opengroup.org/onlinepubs...tions/read.html

I/O is intended to be atomic to ordinary files and pipes and FIFOs. Atomic
means that all the bytes from a single operation that started out together
end up together, without interleaving from other I/O operations.

Two write()s of the same file description should never write at the same
offsets. But in the fork() example which process comes first is undefined.

--
Daniel

[ Post a follow-up to this message ]

Daniel Rock wrote:

> I/O is intended to be atomic to ordinary files and pipes and FIFOs. Atomic
> means that all the bytes from a single operation that started out together
> end up together, without interleaving from other I/O operations.

Where do you see anything that suggests that I/O should be atomic to
ordinary files? That is 100% untrue.

DS

[ Post a follow-up to this message ]