utility@cs.mcgill.ca (Ronald BODKIN) (02/14/91)
Does anyone have any ideas on making XLISP handle asynchronous events, i.e. how can one have a signal routine execute an xlisp form and then return control to a previously executing one? I'm interested in something like having a timer set a signal few seconds, and executing code to handle this situation. Ron p.s. by signal I mean the ANSI-C type of signal
tony@oha.UUCP (Tony Olekshy) (02/26/91)
In message <1991Feb25.061127.6529@cs.mcgill.ca>, utility@cs.mcgill.ca Ronald BODKIN writes: > > [...] 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? The *only* thing you can safely do in a signal handler, in c, and be portable, is set a flag, and perhaps only a flag of type sigatomic_t. This has been discussed at length in comp.lang.c, and there's nothing David can do about it. Fortunately, the flag setting technique works nicely with the evalhook technique. -- Yours etc., Tony Olekshy. Internet: tony%oha@CS.UAlberta.CA BITNET: tony%oha.uucp@UALTAMTS.BITNET uucp: alberta!oha!tony There is nothing more dreadful than imagination without taste. --Goethe
tim@hpfcbig.SDE.HP.COM (Tim Mikkelsen) (02/27/91)
> 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