mit-scheme-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MIT-Scheme-devel] multi-threading problem: Unassigned variable: roo


From: Matt Birkholz
Subject: Re: [MIT-Scheme-devel] multi-threading problem: Unassigned variable: root-continuation-default
Date: Thu, 26 Apr 2012 13:29:33 -0700

> From: "Micah Brodsky" <address@hidden>
> Date: Thu, 26 Apr 2012 11:10:47 -0400
> 
> For your thread to have a sensible dynamic extent to run in, you probably
> want to do something like
> 
> (call-with-current-continuation
>   (lambda (k)
>     (create-thread k thunk)))
> 
> [...] I think what's happening is you have a simple default root
> continuation that, within it, doesn't have a default root
> continuation set.

I think so too.  The REPL provides a sensible default, but only for a
child thread.  It is apparently less than "sensible" for a grandchild
thread, created by the child, to share the REPL's dynamic state.

This works without consing another continuation AND sends the "ok" to
the far side.

(let ((socket (open-tcp-server-socket 54321))
      (k (create-thread-continuation)))
  (create-thread k (lambda ()
                     (let ((sock (tcp-server-connection-accept socket #t #f)))
                       (create-thread k (lambda ()
                                          (display "ok\n" sock)
                                          (close-port sock)))))))

> While you're at it, do be careful about using sockets from multiple
> threads simultaneously. They're not really thread-safe like native
> OS sockets are. [...]

Ummm... one should be careful when using ANY resource from multiple
threads... so Scheme's ports/sockets each come with a mutex... so I
can only wonder what you're on about...  How "really thread-safe" are
"native OS sockets"?

> (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.

Continuations are a lower-level facility, and within-continuation
is not thread-aware, e.g. it does not change (current-thread).
You are using within-continuation to "call back to the original"?
It sounds like you switch stacks only to switch dynamic states.
Wouldn't get/set-dynamic-state! be more... direct?

> 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 shouldn't matter which thread created a continuation.

It IS a bad thing to ask about a "target thread orphaned in some way"
without giving any more details.  What "target" thread?  How so
"orphaned"?

Maybe you should put these tangents in quadruple parens, like this

    ((((Incidentally... meh.))))

so we know you know you are WAY off in the weeds. ;-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]