Re: threads and kill-buffer

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > I think we should try to arrange things in such a way that for a
 > thread that has this buffer as current everything looks and feels
 > as if the buffer were not killed at all.

This isn't possible.  If the thread wants to do anything further with
this buffer, it must do so before switching buffers, because the
current (dead) buffer will become inaccessible as soon as it does
switch buffers.

Even to the extent that it is possible, I don't see why it's a good
idea.  Suppose the buffer is being used as (gasp!) a buffer, more
precisely, a message queue.  If the writer is done, and kills the
buffer, the reader wants to detect this after it's done reading, and
quit reading.  Under your semantics (including your proposal that the
KILLED_BUT_NOT_DEAD state not be available to Lisp), it can't.
Similarly, if the reader is done, and kills the buffer, the writer
wants to detect this *before* writing any more, and quit writing.

So here we have two extreme scenarios, one where the thread whose
current buffer has met an untimely death wants to stop immediately,
and another where it wants to finish up what it's doing completely.
It's not hard to imagine cases where a killed current buffer is an
error.  So the code needs to be able to find out the state of a
buffer.

The question is whether it's useful for there to be a third state.  I
don't think so; everything you need to know is encapsulated in the
fact that the buffer is dead (to the rest of Emacs) and current.