Marc,

> Under what authority does T3 terminate T1?  As I have pointed out in
> the spec, thread-terminate! must be used very carefully to avoid
> stopping a thread at an "unsafe" point (such as in the middle of a
> critical section).

But that was exactly the point of the original example: T1 was NOT in
an explicit critical section, when it was killed. As I understand the
example uses mutexes specifically for the purpose _other_ than to
introduce a critical section.

It appears that you have already given a solution to the problem.
In a message
	http://srfi.schemers.org/srfi-18/mail-archive/msg00038.html
you showed an example that uses a mutex just to guard a critical
section. If that example is modified as

    (define (put! obj)
      (mutex-lock! mutex)
      (let loop ()
        (if full?
            (begin
              (condition-variable-wait! put-condvar mutex)
              (loop))
            (begin
              (set! cell obj)
              (set! full? #t)
              (condition-variable-signal! get-condvar)
              (mutex-unlock! mutex)))))

(that is, signaling on condvar is moved inside the critical section),
the example seems to become immune to the unsafe dying problem. When a
thread T1 executes put! and enters a critical section, and is later
killed or throws a lethal exception at _any point_ after mutex-lock!,
the mutex becomes abandoned. Therefore, a thread T2 that wishes to
manipulate the mailbox will have to deal with a "abandoned mutex
exception". At least T2 will be alerted to the fact the mailbox is
stale and has to be avoided. In the original example, if thread T1 is
killed at an unfortunate moment, T2 will just block forever. T2 will
never find out that the data structure, mailbox, became
inconsistent. It appears one can even claim that in the latter
example, the mutex is not-abandoned if and _only_ if the mailbox is
consistent and will not cause a deadlock for any thread that wishes to
use it.