c/unix q
E.S. Rosenberg
esr+linux-il at g.jct.ac.il
Thu Jun 6 17:45:24 IDT 2013
2013/6/6 Erez D <erez0001 at gmail.com>:
>
>
>
> On Thu, Jun 6, 2013 at 5:29 PM, E.S. Rosenberg <esr+linux-il at g.jct.ac.il>
> wrote:
>>
>> re:all, forgot to change my from field.
>>
>> 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.
>
> that doesn't help
>
> sunday: parent creates a pipe
> monday: parent forks for child 1. parent closes write. child 1 closes read.
> child 1 now can write and parent can read.
> tuesday: parent forks for child 2. child 2 can not write - pipe already
> close by parent on monday.
Seriously?
Just have the parent request another child from the child, or create a
child who's specific task is spawning the worker children, or any of
the other many solutions to this problem.
>
>>
>> >>
>> >> >
>> >> >>
>> >> >> 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
>> >> >
>> >
>> >
>
>
More information about the Linux-il
mailing list