pseudo terminals in 7.0 - pts implementation

[Robert Watson]

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
>