On Thu, Jun 6, 2013 at 5:45 PM, E.S. Rosenberg <[email protected]>wrote:
> 2013/6/6 Erez D <[email protected]>: > > > > > > > > On Thu, Jun 6, 2013 at 5:29 PM, E.S. Rosenberg <[email protected] > > > > wrote: > >> > >> re:all, forgot to change my from field. > >> > >> 2013/6/6 Erez D <[email protected]>: > >> > > >> > > >> > > >> > On Thu, Jun 6, 2013 at 5:04 PM, E.S. Rosenberg <[email protected]> > wrote: > >> >> > >> >> 2013/6/6 Erez D <[email protected]>: > >> >> > > >> >> > > >> >> > > >> >> > On Tue, Jun 4, 2013 at 6:09 PM, Shachar Shemesh < > [email protected]> > >> >> > 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 > >> >> > [email protected] > >> >> > http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il > >> >> > > >> > > >> > > > > > >
_______________________________________________ Linux-il mailing list [email protected] http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
