Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!hpfcso!hpfcbig!tim
From: tim@hpfcbig.SDE.HP.COM (Tim Mikkelsen)
Newsgroups: comp.lang.lisp.x
Subject: Re: Re: signals in XLISP.
Message-ID: <1170015@hpfcbig.SDE.HP.COM>
Date: 27 Feb 91 06:38:13 GMT
References: <1991Feb13.201943.20045@cs.mcgill.ca>
Organization: HP SESD, Fort Collins, CO
Lines: 27

> While this would work, it suffers from the problem that you are
> really polling instead of getting interrupted.  Another user suggested
> something similar (do it while waiting on a read), but I was hoping that
> someone could suggest how one might allow the safe execution of lisp
> forms from within a signal handler.  Maybe I should email David Betz?
> 	Ron

(When you get right down to bits and CPUs, everything is polling.  :-)

I've spent a good share of my  professional  life  dealing  with I/O and
interrupts within BASIC (and other language) interpreters.  This 'end of
line'/polling  approach  is the way that I have  seen it done.  To do it
other  ways  (i.e.  direct  interrupts)  requires a great  deal of state
saving and language-environment  complexity to make sure you don't screw
up the  main-line  program.  You  also  need to make  sure  that you can
effectively  communicate  between  the two  programs.  And  this is very
difficult if you want to allow for ugly programming constructs like loop
and function  aborts/exits and goto style constructs (from the interrupt
out to the main routine).

One  interesting  approach  would be to actually  have a separate  XLISP
interpreter  tied to the interrupt  handler.  XLISP is small enough, you
could  probably  get away with  this.  There  would be some  interesting
questions  to  resolve  about  how  to  get  the  two   environments  to
communicate.

Tim Mikkelsen