At Fri, 09 Nov 2018 18:27:09 +0900, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote in
<5BE552ED.4040304@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