Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!gatech!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Number of ptys (was prwopen: A popen-like routine using ptys)
Message-ID: <59@umcp-cs.UUCP>
Date: Tue, 4-Mar-86 05:52:26 EST
Article-I.D.: umcp-cs.59
Posted: Tue Mar  4 05:52:26 1986
Date-Received: Fri, 7-Mar-86 05:25:48 EST
References: <1411@garfield.columbia.edu>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 34

The posted `prwopen' routine has inside it a bit of short-sightedness
that has long been propagated from what was probably purely an
efficiency hack.  Specifically, in its pty scan routine, it says
(paraphrased):

	for (c = 'p'; c <= 's'; c++) {
		sprintf(name, "/dev/pty%c0", c);
		if (stat(name, &st))
			break;
		...
		if (ok)
			goto gotpty;
	}
	no ptys are available
	do something special

This puts a limit of 64 on the number of ptys that will be tried.
64 might seem like a lot on a 780, but a 780 is not a very big
machine.  Someday, someone will run out.

That day has already come.  We have 80 ptys on our 8600.

The middle condition in the for loop should simply be removed.  If
there is no /dev/ptyt0, the stat will fail.  Sure, that is more
expensive than the test `c <= 's'', but who cares?  And if there
IS another set of ptys, why not try them?

(Of course, there really should be a better way to do the whole
thing.  But until then, why put artificial limitations on what we
have now?)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu