[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
`hanging' pipes and zeroed tty pgroups...
> quoted from dosmem.c, line 707:
>
>>/* release the controlling terminal, if we're a process group leader */
>> fp = curproc->handle[-1];
>> if (fp && is_terminal(fp) && curproc->pgrp == curproc->pid) {
>> struct tty *tty = (struct tty *)fp->devinfo;
>> if (curproc->pgrp == tty->pgrp)
>> tty->pgrp = 0;
> ^^^^^^^^^^^^^
> i think this is a bug :-)
>
> no patch because i'm not sure what exactly to do here (well search for
>another process that has the same ctty, but in what order... anyone?)
>but you can reproduce the effect when you do something like `sh -c ps |less'
>(tried with BSD sh and ksh) and then try to interrupt or stop less with
>^C or ^Z. either nothing happens (running on /dev/fasttext) or you kill
>everything (running on toswin)...
I think I'm responsible for that code. It was supposed to be a fix
for the buggy job control code, which has been removed from MiNT.
That code used a pgrp of 0 on a tty to indicate that it was "up for
grabs" (the next process to read/write on the tty would become the tty
owner).
I think it can be safely commented out now. There should not be any
need to change the process group at all, it should be OK to just leave
it in owned by the exited process.
--
entropy -- it's not just a good idea, it's the second law.
Personal mail: entropy@gnu.ai.mit.edu
MiNT library mail: entropy@terminator.rs.itd.umich.edu