Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!hplabs!pyramid!pyrps5.pyramid.com!mre
From: mre@pyrps5.pyramid.com (Mike Eisler)
Newsgroups: comp.unix.wizards
Subject: Re: ptem's limitations
Keywords: ptem
Message-ID: <156391@pyramid.pyramid.com>
Date: 23 May 91 03:45:36 GMT
References: <1991May20.145454.682@arizona.edu> <7976@auspex.auspex.com>
Sender: news@pyramid.pyramid.com
Organization: Pyramid Technology Corporation, Mountain View
Lines: 22

In article <7976@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>In article <1991May20.145454.682@arizona.edu> cat@pluto.dss.com (Iain
>  Wacey) writes:
>>of some limitation of ptem. It does not handle flow control
>>leaving it to any lower module or driver to handle STOPI
>>messages from ldterm.
>
>It doesn't handle flow control coming into the pseudo-tty, no; it leaves
>that up to the streams mechanism to handle, just as other pseudo-tty
>mechanisms do.

Trouble is, ptem doesn't use streams flow control to handle ^S/^Q
correctly. When a STOP message comes down from ldterm (as a consequence
of ldterm getting ^S), ptem queues it rather than forwarding it to the
lower module. Unfortunately ptem has no service procedure. When a
module above ptem attempts a canput(), the canput() succeeds, because
canput() skips modules without service procedures.  So the application
can forever write data over a pseudo tty that is supposedly flow
stopped by ^S forever.

	-Mike Eisler
	mre@pyramid.com