pseudo terminals in 7.0 - pts implementation

[Dan Epure]

Hi Robert,

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 ? 


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