another 1.10 job control bug?

["Nicholas S Castellano" <entropy@terminator.rs.itd.umich.edu>]

A few days ago, you said:

>Date: Thu, 3 Mar 94 19:58:24 CET
>From: Juergen Lock <nox@jelal.north.de>

>+#else
>+/* release the controlling terminal, if we're the last member of this pgroup */
>+	fp = curproc->handle[-1];
>+	if (fp && is_terminal(fp)) {
>+		struct tty *tty = (struct tty *)fp->devinfo;
>+		int pgrp = curproc->pgrp;
>+
>+		if (pgrp == tty->pgrp) {
>+			PROC *p;
>+			int found = 0;
>+
>+			for (p = proclist; p; p = p->gl_next) {
>+				if (p->pgrp == pgrp && p->handle[-1] == fp)
>+					found++;
>+			}
>+			if (!found)
>+				tty->pgrp = 0;
>+		}
>+	}
>+#endif

It turns out this is one big no-op.  At the time terminate() is
called, the exiting process still exists in proclist.  So 'found' is
always incremented at least once (when the exiting process whose
controlling terminal we're looking for is encountered) and the code to
set tty->pgrp = 0 is never reached.

This may be the cause of the problem someone else reported with using
the modem ports under a patched mint.

Replacing the loop with:

			for (p = proclist; p; p = p->gl_next) {
				if (p->pgrp == pgrp && p->handle[-1] == fp
				    && p != curproc)
					found++;
			}

...seems to do the right thing more often.

--
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
"what do you have against octal?" -jrb