|
From: Alastair B. <ala...@gm...> - 2010-11-05 02:55:22
|
You're using a non-cygwin emacs. Cygwin emacs uses some crazy combination of named pipe and monitor thread to deliver such signals, and SBCL isn't hooked into it and thus ignores it. Non-cygwin emacs generates a console "break" event... and SBCL isn't hooked into it and thus gets smote by the console subsystem. This is a long-known issue. How long? It's item 4e at http://www.dridus.com/~nyef/TODO.Win32 which was written post-merge, but not by long. I can think of three possible ways to improve the situation. First, calling SetConsoleCtrlHandler() with the right combination of args will effectively "mask" the interrupt. Second, a bit of runtime hacking involving calling SetConsoleCtrlHandler() and using the thread and debug APIs and checking pseudo-atomic, /et cetera/ could possibly make something happen. Third, wait until win32 threading is added and use that as a starting point. Hope this helps, -- Alastair Bridgewater On Thu, Nov 4, 2010 at 8:20 PM, Mark H. David <mh...@yv...> wrote: > Yes, Windows XP. > > Stas Boukarev wrote: > >> "Mark H. David"<mh...@yv...> writes: >> >>> Whenever I do slime-interrupt in a repl running SBCL, it shuts down the Lisp completely, and I have to manually clean up the buffers. >>> >>> SBCL version 1.0.37. Latest SLIME. Anyone know if this is known, and/or if there's a fix? >> Is that on Windows? >> > > ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > http://p.sf.net/sfu/SAP-dev2dev > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |