From: Matthew Flatt <mflatt@cs.utah.edu>
To: plt-scheme@list.cs.brown.edu
Date: Fri, 14 Mar 2003 10:09:31 -0700
Subject: [plt-scheme] 203.6

The exp-tagged code for MzScheme and MrEd is now version 203.6.

--------------------

This version completes a project to support kill-safe synchronization
abstractions. From a while back:

At Wed, 12 Feb 2003 13:21:47 -0700, Matthew Flatt wrote:
> At Wed, 12 Feb 2003 14:49:35 -0500 (EST), Paul Graunke wrote:
> > If message passing is such a widespread, useful means of communicating
> between
> > threads (Erlang stuff, the Web server, DrScheme’s REPL, the Stepper?) then
> > we should really have a mechanism that works well with custodians.  Maybe
> > there is some clever way to use call-in-nested-thread to make a thread
> > that won’t die do the queue manipulation.
>
> [...]
>
> I’m fairly certain that MzScheme v203.4 doesn’t support such a library,
> no matter how clever the implementor. This problem has bothered me for
> a long time, but I think I’ve finally arrived at a solution. If all
> goes well, v203.5 will include a small addition that enables kill-safe
> abstractions without sacificing any of MzScheme’s existing guarantees
> for termination and isolation.

It turns out that I didn’t have the solution. Robby came to visit, and
we worked out a better approach.

It also turns out that Paul was right about message-passing channels;
it’s a better foundation than the approach I was trying before. More
generally, we started introducing Concurrent ML constructs in v203.5 to
build on the best base that we can find.

Version 203.6 completes the "Concurrent MzScheme" implementation by
adding synchronous channels and by cleaning up certain GC issues. There
are some minor improvements to CML, I think, with respect to
nack+exceptions and polling. But the major improvement results from the
combination of CML’s primitives, MzScheme’s custodians, and two further
additions: `thread/suspend-to-kill’ and the 2-argument form of
`thread-resume’.

Explaining all of this is my job for the next couple of weeks, and I
won’t try hard to do it today. Meanwhile, CML fans may want to check
out "plt/collects/mzlib/async-channel.ss". It’s an essentially standard
CML implementation of buffered asynchronous channels, which involves a
private thread to manage the buffering. The new part in the
implementation is that, to users of an asychronous channel, the channel
is independent of any custodian, despite the private thread.
Consequently, the channel can be used by otherwise distrustful
processes. Still, the channel doesn’t open any "security holes";
DrScheme can certainly kill off all private channel threads in a
program that it runs.

More generally, I think that if you can express an abstraction in CML,
you can easily express it in a kill-safe way in MzScheme.

--------------------

Changes:

 * Added synchronous channels a la CSP (by way of CML).

 * Added `thread-suspend’ and `thread-resume’, with the obvious
   meanings when given a single thread.

   In addition, the `thread-resume’ procedure accepts two threads: the
   first one is resumed, but also "promoted" by changing its managing
   custodian. The new managing custodian is the youngest superordinate
   custodian of the ones that currently manage the two threads.

   The idea is that every time someone uses a synchronization
   abstraction that has a private thread, the private thread is
   promoted using the current thread.

 * Added `thread/suspend-to-kill’. Thus function is like `thread’, but
   when the thread is "killed" via `kill-thread’ or
   `custodian-shutdown-all’, it is actually merely suspended.

   There’s no difference between kill and suspend if the thread is
   inaccessible, so we haven’t lost the ability to kill processes. In
   principle, we could (should?) replace `thread’ by
   `thread/suspend-to-kill’. But threads are a consistent source of
   conservative GC trouble (due to copying the stack and registers), so
   we’ve decided to preserve non-suspending kills as a hint to the
   run-time system.

 * Added `thread-dead?’, since `thread-running?’ now reports #f for a
   suspended thread.

 * Added `thread-suspend-waitable’, `thread-resume-waitable’,
   and `thread-dead-waitable’.

 * Renamed `make-nack-waitable’ to `make-nack-guard-waitable’
   to claify its relation to `make-guard-waitable’.

 * Added `make-poll-guard-waitable’.

 * Changed unreachable threads to be garbage-collected when blocked on
   any combination of otherwise unreachable waitables via
   `object-wait-multiple’, `semaphore-wait’, `channel-put’,
   `channge-get’, or `thread-wait’. In addition, unreachable suspended
   threads are garbage-collected.

   In other words, thread GC works like it should (modulo conservative
   ills).

 * Added "async-channel.ss" to MzLib (and they’re kill-safe!).

Matthew