From: Matthew Flatt <mflatt@cs.utah.edu>
To: plt-scheme@po.cs.brown.edu
Subject: [plt-scheme] 205.10
Date: Sat, 20 Dec 2003 13:57:03 -0700

The exp-tagged code in CVS for MzScheme and MrEd is now version 205.10.

IMPORTANT CHANGE: After a custodian is shut down, it cannot manage new
objects.

Changes:

 * `custodian-shutdown-all’ permanently disables a custodian.

    Previously, a shut-down custodian remained available for managing
    new objects, which would be shut down by any future application of
    `custodian-shutdown-all’ on the custodian.

    Existing programs rarely re-use a custodian after it’s shut down, I
    think. Except for the test suite, the only example of this usage I
    could find is in the MrEd paper and talk.

    The new rule for custodians is generally easier to reason about,
    especially when processes that are managed by different custodians
    can communicate. For example, suppose process A has communicating
    subprocesses B and C, each its its own subcustodian. With reusable
    custodians, it’s not enough to shut down B’s custodian and C’s
    custodian to terminate both B and C, because between those
    shut-downs, C might manage to start new threads using B’s
    custodians. This kind of race condition is no longer possible.

 * A thread can have multiple custodians.

   Extra custodians are acquired through the 2-argument form of
   `thread-resume’ (revised). If a thread has multiple custodians, then
   shutting down any one of the custodians does not kill the thread,
   but instead simply removes the custodian from the tread. A thread is
   killed when it has no custodians. Note that a thread created with
   `thread/suspend-to-kill’ can end up suspended and without
   custodians; such a thread can be resumed only by giving it a useful
   custodian.

 * Added thread groups.

   Thread groups, which contain threads and other thread groups, are
   for scheduling: every thread/group in a particular group has equal
   claim to the CPU (through round-robin scheduling).

   In particular, a subprocess’s CPU usage can be effectively
   controlled by creating a group for the subprocess’s threads.
   Otherwise, the subprocess could take over the CPU by creating
   arbitrarily many threads.

   Thread groups are unrelated to custodians (i.e., a thread’s
   custodian doesn’t determine it’s group, or vice-versa).

Matthew