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

[Matt Birkholz]

> From: Taylor R Campbell <address@hidden>
> Date: Thu, 26 Apr 2012 22:01:29 +0000
> 
>    Date: Thu, 26 Apr 2012 13:29:33 -0700
>    From: Matt Birkholz <address@hidden>
> 
>    > From: "Micah Brodsky" <address@hidden>
>    > Date: Thu, 26 Apr 2012 11:10:47 -0400
> 
>    > 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"?
> 
> The mutex in a port is advisory, not mandatory.  MIT Scheme uses it
> only to grant ownership of the `console port' to a single thread.
> Concurrent use of a port in two different threads can corrupt its
> internal state.  Concurrent use of a file descriptor (or `native OS
> socket', or `channel') from two different threads can't corrupt its in
> internal state.

You seem to think "native OS sockets" are channels, but Micah is
talking about a Scheme port -- more comparable to a libc "stream", no?
Do the latest libcs ensure putc and getchar are thread-safe?  (I hope
not: what a waste!)

What's the point?  In practice you need to ensure that the large-ops
like readline or run-list-command are atomic (per port).  Tiny amounts
of write/read-octet consistency are no help at all.

Sequence the large-ops and the micro-ops will behave themselves.

A REPL that grabs its i/o port's mutex once at startup and then reads
and writes it freely is an example of that principle in action.