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

[Taylor R Campbell]

   Date: Fri, 27 Apr 2012 18:40:16 -0700
   From: Matt Birkholz <address@hidden>

   ... and let's get concrete with the existing thread-event mechanism.

Please don't.  It's extremely hard to engineer anything reliably with
it.  Any discussion of SIGNAL-THREAD-EVENT that doesn't involve
blocking and unblocking thread events, race conditions, atomicity and
data structure invariants, &c., is a recipe for disaster.  We need to
get rid of it except, at most, as a debugging operation and as an
internal mechanism for implementing more principled abstractions.

One example of a more principled abstraction is Scheme-CML, based on
Concurrent ML:

http://mumble.net/~campbell/darcs/scheme-cml/

We also need a better story about interruption, perhaps like Racket's
breaks, but not as the basic mechanism for thread communication.

   > [...] Imagine if you couldn't safely do debug prints from a worker thread!

   I can only imagine doing it safely if the debug-print procedure grabs
   the port/mutex for the duration of the message output (write-line?)
   process.

It doesn't help for the debug-printing routine to grab a mutex if
nobody else is cooperating with it.  And if you're desperately chasing
down a thread synchronization problem with debug-prints, there's a
good chance someone has forgotten to cooperate.

             A write-line made up of tiny atomic write-chars is no more
   "safe" except for the precious buffer pointers.  I would call them a
   costly set of suspenders IF they kept the pants from falling down.
   Thread-safe and child-proof are marketing terms.

Interleaving output is one thing.  Crashing because of corrupted
internal data structures is quite another.

   > MIT Scheme has some particularly bad failure modes when you rub its
   > sockets the wrong way from multiple threads, i.e. producing an
   > infinite explosion of interrupt-triggered errors that surfaces on
   > socket close, well after the offending code has run, and almost
   > un-debuggable because all you can interact through is the interrupt
   > menu. The only way I figured that one out is by asking Taylor to
   > tell me what I did wrong. :P

   Fascinating (as my hero would say, without a trace of sarcasm).

   What did you do wrong?

One easy way is to close a channel that someone's waiting to do I/O
on.