[TUHS] non-blocking IO - threads

Paul Winalski paul.winalski at gmail.com
Thu Jun 4 02:42:28 AEST 2020

On 6/2/20, Jon Steinhart <jon at fourwinds.com> wrote:
> Maybe I should explain what I meant by messy.  To me, the issue with select is
> that in many cases one has to either keep a lot of state somewhere, or live with
> long response times while handlers complete.  Threads allowed handlers to be
> written in the "normal" way with state kept on the stack.
TOPS-10 had a nifty program called ptycon that would allow one to
control multiple login sessions, each on its own pseudo-terminal
device, from a single physical terminal.  In 1985 our software tools
group implemented a pseudo-terminal device driver for VMS, and I wrote
a program called ptycon-32.  It was multithreaded, with one thread of
control for each pseudo-terminal.  The problem is that VMS at the time
didn't have a threads package.  I had to roll my own threads by using
the asynchronous system traps (ASTs) delivered by completion of I/O to
the pseudo-terminals.  Talk about messy....

-Paul W.

More information about the TUHS mailing list