Alan Ruttenberg alanralanr@comcast.net writes:
When there are multiple processes and an interrupt is sent, lisp(openmcl in my case) needs to know which process to interrupt. So when the interrupt is being processed I need to ask emacs for that information before choosing the process to interrupt. What's the proper way to do that?
I don't think there is a proper way as of today. The Emacs side has no notion of threads, so is there anything useful it can tell Lisp at all?
How will you interrupt a specific thread in OpenMCL? Do they each have their own OS PID such that you could SIGINT the right one, or is it necessary to do a (interrupt-thread T) sort of call inside Lisp? (I think the first will work in SBCL and the second will be needed in CMUCL).
If the second, a temporary hack could be to have Emacs send e.g. SIGUSR1 and Lisp have a handler that knows to interrupt the Swank request-handler thread, or something..
Also regarding multiple processes: I'm running portable aserve and would like to be able to have errors that occur in the server processes create a slime debugger instance. Is there a way to set that up, given that those processes are not associated with a repl?
We have no reliable way to do this. The unreliable (kinda okay with SERVE-EVENT, probably suicide with threads) is in .emacs:
(setq slime-global-debugger-hook t)
That way *DEBUGGER-HOOK* will be globally bound to contact Emacs, always using the same connection, come-what-may. My previous attempt at multiprocessing support just added locks to this so that only one thread would talk to Emacs at a time.
But hopefully the multiple-session support will fix all this. Today it would be possible for Emacs to connect to multiple Swank servers each run by a different thread in the same Lisp. The trick is just to hack in support for creating these extra connections on-demand (e.g. when a thread hits the debugger). I was planning to hack that up on the weekend if I get time, but you're welcome to beat me to it too :-)
Cheers, Luke