From ...
Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!news-x2.support.nl!newsfeed.wirehub.nl!newsfeed00.sul.t-online.de!t-online.de!newsfeed.esat.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader2.kpnqwest.net.POSTED!not-for-mail
Newsgroups: comp.lang.lisp
Subject: Re: Lisp apps, threading, & debugging
References: <msb45a.gpv.ln@rabbit.ddts.net> <sfw8z9lg6lu.fsf@shell01.TheWorld.com>
Mail-Copies-To: never
From: Erik Naggum <erik@naggum.net>
Message-ID: <3223365881868925@naggum.net>
Organization: Naggum Software, Oslo, Norway
Lines: 40
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 22 Feb 2002 11:24:37 GMT
X-Complaints-To: newsmaster@KPNQwest.no
X-Trace: nreader2.kpnqwest.net 1014377077 193.71.199.50 (Fri, 22 Feb 2002 12:24:37 MET)
NNTP-Posting-Date: Fri, 22 Feb 2002 12:24:37 MET
Xref: archiver1.google.com comp.lang.lisp:27107

* Kent M Pitman <pitman@world.std.com>
| And there was an issue with the LispM telnet for many years regarding
| asynchronous interruption--it required an extra process to listen on
| the input stream and find the asynchronous-abort-request character and
| process that ahead of other pending characters in order not to have
| computations that just lock up and don't listen to the telnet port any
| more.  There may be other ways to implement this, and I don't know if
| CMU's repl deals with any of this... just something to watch out for.

  Implementing a full TELNET client or server is about two weeks' worth of
  hard labor (each) for one who knows the standards involved.  It is not
  something you whip up in an hour or two just by making or accepting
  connections.  TELNET is a protocol that needs a dedicated programmer's
  full attention.  Option processing in TELNET has non-trivial consequences
  and should not be ignored because they are mostly not used.  The typical
  90% solutions of TELNET server or client causes loss of data and/or
  lockup of the connection.  In particular, interrupt processing is hard to
  get right.  Personally, I _really_ like the Are You There facility and
  use it to test TELNET implementations.  Very few get it right.

  <nostalgia Back in TOPS-10 and TOPS-20 days, and probably elsewhere,
  typing ^T (the canonical AYT binding), produced a system status line
  including system load, number of processes, what your process was doing
  or waiting on, etc.  All extremely useful information when working a
  system taht occasionally went unresponsive.  Sadly, the pathetic Unix
  terminal drivers and shells and telnet/remote shell clients are _miles_
  short of the real thing.>

  Unfortunately, if you write a real TELNET client, nobody wants to use it,
  because they think the retarded HTTP-style interaction is what network
  protocols should be like, and the only kind of state machines programmers
  of today are used to working with are regular expressions, and they do
  not even understand how _those_ work.  I fault this incredibly stupid
  marketing for "object-orientation" as the panacea for the demise of the
  state machine.

///
-- 
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.