At Fri, 09 Nov 2018 18:27:09 +0900, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote in <5be552ed.4040...@lab.ntt.co.jp> > > Ok, I can live with that with no problem. > > OK ... > > I think Thomas just saying that reading more lines can develop > > problems. According to the current discussion, we should error > > out if we had SEGV when limit 1. > > Ah, I misread that. Sorry for the noise.
Being said that, the ruby case may suggest that we should be more tolerant for the crash-after-limit case. > > In my understanding processes not connected to a > > terminal(tty/pts) cannot receive TTIN/TTOU (unless someone sent > > it artifically). Since child processes are detached by setsid() > > (on Linux), programs called in that way also won't have a > > controlling terminal at the start time and I suppose they have no > > means to connect to one since they are no longer on the same > > session with postmaster. > > For TTIN and TTOU, we would first need to make clear the reason for > the inconsistency Thomas pointed out. I'm wondering if we should > leave the TTIN/TTOU stuff for future work. Inconsistency? I read the Thomas's messages as "TTIO/TTOU are not needed to our busines and we don't have a reason to restore them before calling external programs other than just plaster seemingly consistency." And I agree to the analysis and I agree to you on the point that it doens't need consideration just now. If the consistency means the different behaviors between perl and ruby, (as written in another message,) I'm inclined to vote for having a bit more tolerance for error of external programs as my second patch. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
