Re: [MIT-Scheme-devel] multi-threading problem: Unassigned variable: root-continuation-default

[Matt Birkholz]

> From: "Micah Brodsky" <address@hidden>
> 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).