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

[Taylor R Campbell]

   Date: Thu, 26 Apr 2012 17:47:01 -0700
   From: Matt Birkholz <address@hidden>

   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!)

By `native OS sockets', I understood Micah to mean what you get out of
the socket(2) system call, i.e. file descriptors, whose closest
representatives in MIT Scheme are channels.

libc streams are indeed analogous to Scheme ports, although the libc
stream operations you quoted do lock the stream so that two concurrent
uses of putc, getc, &c., won't hose your stream.

   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.

Although we don't do it, there is a point to making the `micro-ops'
lock the port: then the port's internal data structures won't get
corrupted.  Different threads might get weird views of the input, or
cause interleaved output, but the port itself won't be corrupted so
that a subsequent operation on it will crash.  (There is also an
associated performance loss which is enormous, and which motivated
putc_unlocked, getc_unlocked, &c., in libc.)