c/unix q

[Erez D]

On Thu, Jun 6, 2013 at 5:45 PM, E.S. Rosenberg <esr+linux-il at g.jct.ac.il>wrote:

> 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?
>
yes,  Seriously!

> Just have the parent request another child from the child,

can't do - i do not have the source of the child. ( i do fork+exec )

> or create a
> child who's specific task is spawning the worker children,
>
why complicate things ? such a child takes a lot more resource than a
non-closed side of a pipe
also you have just moved the problem, instead of the parent having a non
closed write side, you have this special child with a non closed write side.

> or any of
> the other many solutions to this problem.
>
any thing simpler that  "not closing a the 'write' side of a pipe in the
parent" ?

> >
> >>
> >> >>
> >> >> >
> >> >> >>
> >> >> >> 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
> >> >> >
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20130606/ec6cec14/attachment-0001.html>