c/unix q

[E.S. Rosenberg]

2013/6/6 Erez D <erez0001 at gmail.com>:
>
>
>
> On Thu, Jun 6, 2013 at 5:04 PM, E.S. Rosenberg <esr at g.jct.ac.il> wrote:
>>
>> 2013/6/6 Erez D <erez0001 at gmail.com>:
>> >
>> >
>> >
>> > On Tue, Jun 4, 2013 at 6:09 PM, Shachar Shemesh <shachar at shemesh.biz>
>> > wrote:
>> >>
>> >> On 04/06/13 15:28, Erez D wrote:
>> >>
>> >> thanks,
>> >>
>> >> so i guess if i use unidirectional connection, and the reader does not
>> >> expect to get an EOF()
>> >> thank i'm safe.
>> >>
>> >> Why are you so keen on doing it wrong?
>> >>
>> >> No, you are not safe. If the child process dies because of a
>> >> segmentation
>> >> fault (or whatever), the parent will notice this through the EOF
>> >> received (I
>> >> am assuming here, since you couldn't be bothered with closing a file
>> >> descriptor, that you did not install a SIGCHLD handler to monitor for
>> >> this
>> >> possibility). This means that should one process die unexpectedly, the
>> >> other
>> >> will hang forever.
>> >
>> > it's not a matter of being bothered. closing a file has it's
>> > implications
>> >
>> > 1.  close the file for one thread closes for all
>> thread and fork are 2 very different things, best practice for fork
>> ('full' children, I think everyone understands fork() when you say
>> child) is to close, when using threads that is I believe not the case.
>> > 2. what if i want later children using the same pipe, as in all childs
>> > write
>> > to same pipe read by parent...
>> so the children are all closing the read end and the parent only
>> closes write, where is the problem?
>
> if the parent closes the "write" side, then new forked children have their
> "write" side already closed.

That's why we are able to check if we are a child or a parent with the
fork() function.
>>
>> >
>> >>
>> >> Best practices are there for a reason, despite what others here might
>> >> have
>> >> you think.
>> >>
>> >> Shachar
>> >
>> >
>> >
>> > _______________________________________________
>> > Linux-il mailing list
>> > Linux-il at cs.huji.ac.il
>> > http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>> >
>
>