> From: "Micah Brodsky" <micah...@csail.mit.edu> > Date: Thu, 26 Apr 2012 22:56:10 -0400 > > This code snippet causes the REPL input to hang until you ^C: > > (call-with-current-continuation > (lambda (k) > [...])) > > Now, I'm not sure that it's *supposed* to work, since if anybody's > ever written up what exactly the thread safety properties the scheme > runtime are, I haven't read it.
Y'er given as much rope as you require, whether you are hanging yourself or whatnot. Here you capture a continuation deep in repl-eval, BEFORE the trouble in repl-read. AFTER repl-read is all set up, your new thread jumps to that ancient continuation via within-continuation, which unwinds block-on-io-descriptor, which de-registers the console-thread's io-registration. With no threads running and no io-registrations, Scheme goes into what is described in the commentary as a regrettable busy-wait. So... you probably shouldn't do that. > If it's not supposed to work, then there's no need to worry about > the fact that it doesn't! I DID just smack that demon down with a new incantation of block-on-io-descriptor. You can speak that particular profanity in the REPL now without stunning the console-thread, but I don't doubt you can get yourself in another fix if you keep on like THAT! > I had not thought of using set/get-dynamic-state. That > seems... dirty? Dirtier than within-continuation'ing to whither and whence? > (It probably would also suffer many of the same potential problems > depending on what thread-specific dynamic state the runtime may be > squirreling away that I'm unaware of.) As far as I am aware, you are only unaware of state-space:global (fluid-lets) and state-space:local (dynamic-winds). _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
