With this patch the child is guaranteed to not be in the foreground (as far
as the tty knows) so it will be getting SIGTTIN and possibly SIGTTOU on tty
operations.
You may need to correct me. In practice we see that the timeouted program
perform successfully writes to the terminal, though it
shay shimony writes:
With this patch the child is guaranteed to not be in the foreground (as far
as the tty knows) so it will be getting SIGTTIN and possibly SIGTTOU on tty
operations.
You may need to correct me. In practice we see that the timeouted program
perform successfully writes
On 02/07/11 19:36, shay shimony wrote:
With this patch the child is guaranteed to not be in the foreground (as far
as the tty knows) so it will be getting SIGTTIN and possibly SIGTTOU on tty
operations.
You may need to correct me. In practice we see that the timeouted
program perform
On 29/06/11 10:55, Pádraig Brady wrote:
On 28/06/11 20:10, Alan Curry wrote:
=?ISO-8859-1?Q?P=E1draig_Brady?= writes:
I'm still not convinced we need to be messing with tcsetpgrp()
but you're right in that the disconnect between the timeout
process group and that of whatever starts `timeout`
=?ISO-8859-1?Q?P=E1draig_Brady?= writes:
Given the above setsid make example (which hangs for 10s
ignoring Ctrl-C, I'm leaning towards `make` needing to
be more shell like, or at least forward the SIGINT etc.
to the job, and not assume jobs run in the foreground group).
I'm a little worried
On 02/07/11 22:38, Alan Curry wrote:
=?ISO-8859-1?Q?P=E1draig_Brady?= writes:
Given the above setsid make example (which hangs for 10s
ignoring Ctrl-C, I'm leaning towards `make` needing to
be more shell like, or at least forward the SIGINT etc.
to the job, and not assume jobs run in the
