[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