From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keisuke Nishida To: guile-emacs@sourceware.cygnus.com Subject: Re: interrupting the Scheme process Date: Sat, 06 May 2000 08:00:00 -0000 Message-id: References: <20000503205439E.satoru-t@is.aist-nara.ac.jp> X-SW-Source: 2000-q2/msg00032.html Ken Raeburn writes: > Guile has some hooks for recording that an interrupt has occurred and, > at certain times, throwing an exception of some sort. If we could set > that flag at C-g time, if Scheme code is currently running, might that > do the trick? Then Scheme can trap the exception if it wants, but > otherwise we throw back to the containing Lisp call. Propagating the > unwind through possibly multiple lisp<->scheme interfaces could be > hairy though; I haven't looked very closely at that stuff. It seems Emacs catches the interrupt by interrupt_signal in keyboard.c, so we could modify this function so that it also sets the Guile's flag. If this works, we can convert the signal from Guile into a Emacs's quit signal. In case this doesn't work, I don't know what to do. /* This routine is called at interrupt level in response to C-G. If interrupt_input, this is the handler for SIGINT. Otherwise, it is called from kbd_buffer_store_event, in handling SIGIO or SIGTINT. If `waiting_for_input' is non zero, then unless `echoing' is nonzero, immediately throw back to read_char. Otherwise it sets the Lisp variable quit-flag not-nil. This causes eval to throw, when it gets a chance. If quit-flag is already non-nil, it stops the job right away. */ SIGTYPE interrupt_signal (signalnum) /* If we don't have an argument, */ int signalnum; /* some compilers complain in signal calls. */ > Hm...that might be a way to do it. I also wonder if we might have > cases where we want to send the interrupt to multiple threads -- i.e., > if the "foreground" thread is sitting around waiting for N tasks to > finish (e.g., get new news from news.mycompany.com, get email from > pop.mycompany.com, get new news from news.redhat.com, etc), might we > want to interrupt all of them and unwind the main thread only after > they've died off? Probably. We should kill the parent thread and its children at the same time, though I guess we would still need kill-thread to kill detached threads, which are "background" threads. We don't want to close a GTK window, which may run in a separate thread, just by typing C-g, for example. > I suppose we could have a "spawn and wait for multiple threads" > function which implements all of this on top of the scheme^Wplan you > describe, by trapping the interrupt... Anyway, we can't work on this until your Guile-based Emacs appears :) -- Kei