This code snippet causes the REPL input to hang until you ^C:
(call-with-current-continuation
(lambda (k)
(create-thread k
(lambda ()
(call-with-current-continuation
(lambda (j)
(within-continuation k
(lambda () (j #f)))))))))
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. If it's not supposed to work, then there's no need to
worry about the fact that it doesn't! But I have had occasion to *think*
that such code was what I wanted. (In all cases, I also managed to come up
with suitable alternative strategies that avoided the question.)
I had not thought of using set/get-dynamic-state. That seems... dirty? (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.)
--Micah
-----Original Message-----
From: Taylor R Campbell [mailto:campb...@mumble.net]
Sent: Thursday, April 26, 2012 5:58 PM
To: Micah Brodsky
Cc: cra...@gmx.net; mit-scheme-devel@gnu.org
Subject: Re: [MIT-Scheme-devel] multi-threading problem: Unassigned
variable: root-continuation-default
Date: Thu, 26 Apr 2012 11:10:47 -0400
From: "Micah Brodsky" <micah...@csail.mit.edu>
(Incidentally... I have on occasion tried to punt a computation from one
thread into the dynamic extent of a continuation from another thread
using
within-continuation, making sure to call back to the original
continuation
when the computation finishes. While this works fine when all
continuations
are from the same thread, the same code seems to leave the target thread
orphaned in some way, never to return, when the continuations come from
different threads. Does anyone know, is this a Bad thing to be doing?)
It's a bit tricky to do that sensibly, and probably not possible to do it
really sensibly without formalizing delimited continuations and their
dynamic state semantics. But can you show a program that illustrates the
symptom you observe?
_______________________________________________
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
