On Thu, 22 Nov 2007, Dan Epure wrote:
Thank you for your answer. In this case the first problem (gnu screen) does
not deserve any attention because it is related to the ptmx clonig. My goal
is to find a way to increase the number os pseudo terminal. the traditional
256 pty is not sufficient for my needs. Is there any way to do this on
freebsd other than using ptmx cloning ?
John Baldwin has just merged support for up to 1024 ptys using the traditional
pty driver, I believe, to HEAD, and plans (or perhaps has already) merged it
to 7.0. I see no reason not to further merge it to 6.x. I've stuck him on
the CC list also.
Robert N M Watson
Computer Laboratory
University of Cambridge
On Wed, Nov 21, 2007 at 10:00:02PM +0000, Robert Watson wrote:
On Sun, 18 Nov 2007, Robert Watson wrote:
On Sun, 18 Nov 2007, Dan Epure wrote:
7.0-BETA3 still has issues regarding the pts implementation . problems
found: 1. - GNU screen: starting a screen, opening a few windows and
quiting screen leaves the allocated pseudo terminal in use. 100 screen
user, using each one opening 10 windows will deplete the default of 1000
pseudo terminals leaving the system unusable. 2. - 'ls /dev/ptmx' creates
an additional entry in /dev/pty/. when the number of entries equals
kern.pts.max the system became unusable.
The first of these is likely a reference management bug of some sort -- I
find that if I close a pty in screen by exiting the shell, the pts device
is GC'd properly, but if I close it by killing the session with ctrl-k,
then the pts device is not properly GC'd and processes hung off it not
properly killed. I believe that closing the master device is not properly
kicking the slave device and causing its consumers to exit, hence the pts
device not being closd and released. Christian was taking a look at this
a couple of days ago, and I've CC'd him.
The second problem is more tricky, and has to do with the cloning model.
Similar problems can exist with other variations on the ptmx
implementation, and I need to give some thought to how to address this.
Dan,
So, thinking a bit more about the second problem, I think it is inherrent
to the way we've designed the /dev/ptmx cloning model, which is
unfortunate. My current leaning is to disable the ptmx mechanism in 7.0
and put together a revised one for 7.1. The reason to do this is to avoid
encoding the user<->kernel interface for allocating pty's via ptmx along
the current lines, which we'd then need to continue supporting in future
releases. I'm going to spend a bit of time over the next day or two
looking at revising the interface to fix these problems.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
